1I/ Self Sovereign Identity is Highly ‘CENTRALIZED’: How can we fix the Rotten Core of Issuer Reputation?

From IIW

Self Sovereign Identity (SSI) is highly ‘centralized’: How can we fix the rotten core of issuer reputation?


Session Convener: Ankur Banerjee

Notes-taker(s): Peter Langenkamp

Tags / links to resources / technology discussed, related to this session:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


WHITEBOARD PICTURE: See image(s) for these notes in the IIWXXXIV Book of Proceedings here:

https://internetidentityworkshop.com/past-workshops/


Basics: what do we mean by “self-sovereign identity is centralized”?

  1. There are *two* broad approaches (discussed during the session) on how the issuers of digital credentials get to "trusted" status:
    1. There is a list of "known" or "trusted" issuers, perhaps with trusted Decentralized Identifiers (DIDs) that are shared within an ecosystem.
  2. How do you determine the issuers that are trustworthy?


Two approaches

  • list of trustworthy issuers (list in ecosystem is known)
  • Issuer places document on their site, proving they have control over some trustworthy domain
    • if i show control over that domain, I have proved you can trust me


Both seem highly decentralized


In most systems there seems to be a list: these are the trustworthy issuers But how do you get this to scale?


Thoughts & comments

  • Trust frameworks
    • no solution currently solves the problem at hand


Most systems now need a regulator


It would be great if you could take a credential from one context and use it in another on, how do you make it machine readable?

  • Trust framework organizer publishes a list
  • Publicly publish a machine readable gov. file
    • since it's a URL there are many ways this can be shared
    • search engines
  • The user can select which authority they trust


Suppose

  • You install the governance frameworks that you trust
  • credentials can be compared against those governance frameworks
    • You can e.g. see that your employer likes / dislikes / no opinion about the issuer
    • (trust framework just about issuer? isn't it about the combination of issuer and credential type? e.g. you may trust me to issue a proof of attendance credential but not a passport)
    • it's not just about who's the issuer, but also about what they issue. e.g. don't trust them for your address but do trust them for something else
    • what can they attest to? ("is it first hand")


In VGEC(?) we're working with trusted institutions

  • Very different type of trust than SSI trust


An address as issued by the government is different from on issued by your gas or electric company (the latter do not necessarily now whether YOU live there)


A lot of information is obtained second hand, e.g. through a picture.

  • SSI is all about reuse of information
    • can I take it and use it in a second, third or fourth place?
    • do I know this issuer becomes relevant


What is SSI?

  • in the analog world you can have a driver's license or passport, SSI provides a solution for a digital equivalent (you control your data)


Same problem in Germany with a large number of parties that can issue a vaccination credential

  • chained solution (trust chain) an authorization credential is included in the vaccination credential that can prove the authority of the issuer


Multi-party governance over (fields in) schema's - Multi-party schema governance

  • e.g. in the health space, collaboration on creating vaccination schema's


About the chained credentials

  • the idea is still that there is a centralized authority at the basis of this
    • it can be highly effective in many different contexts
    • but still highly centralized


Like SSL/TLS?

  • Web PKI is a mess, but it works for now
  • By moving it down the road, it's now in a context where you can ask different questions
    • different scales
    • different trust roots


It's important to distinguish between the concept of certificate chaining and the method the browser uses to determines what to trust

  • Do it in a way that informs the user, instead of letting the software make the choice (inform the user, let them choose)


With DID you can use one DID to prove ownership over another one (different from 'also known as', which you may not want to use all the time)


There's two questions

  • centralization problem
  • is this issuer supposed to say this in the first place?
    • can probably be solved more easily than the other problem


One authority of a very specific use case, rather than 50 different ones that each try to do all

  • Single authority per country might work
    • but than in the US they need to trust the authorities of other countries
  • It becomes more complicated when you start mixing contexts


You are missing something, get it somewhere else Linkrot, something may have been issued and still be valid

Being able to choose which authorities to trust could be a solution, but might run into a similar 'problem' as we see with search engines where many are available but only two have a significant market share (Google and Bing)

Linting rulesets are good examples of community

Retrieved from "https://iiw.identitycommons.net/index.php?title=1I/_Self_Sovereign_Identity_is_Highly_‘CENTRALIZED’:_How_can_we_fix_the_Rotten_Core_of_Issuer_Reputation%3F&oldid=24386"