- From: Jeremy Townson <jeremy.townson@gmail.com>
- Date: Mon, 22 Mar 2021 13:08:16 +0000
- To: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Cc: Steve Capell <steve.capell@gmail.com>, Drummond Reed <drummond.reed@evernym.com>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAAic94H24CeKEFCQSk0r4t7gsSER_AJnwzZFYSRJcQ4K51vD2w@mail.gmail.com>
and moreover, misunderstanding that lead adopters to think that SSI doesn't really work in practice and back down the centralized identifier route, which was the link I meant to make back to the thread. On Mon, 22 Mar 2021 at 13:05, Jeremy Townson <jeremy.townson@gmail.com> wrote: > > the identifier needs to be nothing more than a transient public key id > that is used as the subject id in each of the presented VCs > > Agreed. But nowhere, really, is this topic discussed. Nor is it really > discussed that the key ids you mention or that pairwise dids used by others > are two ways to implement a common mechanism. Nowhere is this mechanism > really identified, named, etc. This omission seems to give rise to a number > of common misunderstandings in an around adoption. > > On Mon, 22 Mar 2021 at 12:41, David Chadwick <D.W.Chadwick@kent.ac.uk> > wrote: > >> Hi Jeremy >> >> the identifier needs to be nothing more than a transient public key id >> that is used as the subject id in each of the presented VCs. This binds >> them all together and allows the holder to sign the VP to prove possession >> of all of the VCs. Since the key changes for each verifier, then the >> verifiers cannot correlate the different presentations they have received. >> >> The important point here is that the VC ecosystem does not provide a >> correlating handle. The user might, with name and address. But again the >> user might not, by only presenting DoB or age, or gender. But if the VC >> ecosystem always provides a correlating handle (via some persistent >> identifier) then it has limited the user's right to privacy protection, and >> that is not good. >> >> Kind regards >> >> David >> >> >> On 22/03/2021 12:06, Jeremy Townson wrote: >> >> >> The idea of a 'context' for correlation purposes seems to be something >> that cannot be determined a priori. If, for example, I receive, separately, >> a driving licence and a degree cert, I do not know if there will be a >> future scenario where I wish to present licence+degree in a third context, >> as attributes of my common identity. >> >> It is already often stated that there should be no strongly* correlating >> ids in credentials from separate issuers, but the converse is missing in >> VC/SSI documents. There is little to suggest how two separate contexts can >> be tied together by the holder if that's what he and/or the verifier need. >> >> This is needed to prevent id theft by 'holders'. i.e. it is not >> sufficient to present two distinct credentials with an implied assertion >> they are part of a common identity and expect an automated verifier system >> to correlate them securely. (Though I agree that name/dob provide strong >> enough correlation for advertising purposes). >> >> That the holder be in control of such identity contexts -- can keep them >> separate, or provably bind them if and when he wishes -- seems to express >> more cleanly the intent of SSI than statements about the physical layout of >> the issuer systems, whether they use servers, blockchains, etc. >> >> Because identifiers are so crucial to support this, it creates a de facto >> coupling between VCs and identifiers. There thus seems to be a need to >> tackle this issue vertically (even if VCs and DIDs are distinct horizontal >> layers). I agree with David, that the principles could be clearer in this >> area and suggest the things above as one way we could improve. >> >> >> On Mon, 22 Mar 2021 at 10:58, Steve Capell <steve.capell@gmail.com> >> wrote: >> >>> Isn’t it because a subject can self -issue as many did as they like - >>> for as many different contexts as they like - limiting the potential for >>> correlating aggregation to only the claims about the same did ? And even >>> then, the multiple claims would have to be presented to the same or >>> collaborating verifiers >>> >>> Conversely, even if I minted a new did for every vc, or even didn’t use >>> dids at all, verifier will still typically pull something like my given >>> name / family name from VC and so will have a correlating identity )maybe >>> not globally unique ) in any case? >>> >>> Centralised hubs like Facebook will always try to aggregate data, VC or >>> no VC. We are just giving holders a bit more power and a bit more autonomy >>> if they choose to use it wisely >>> >>> Steven Capell >>> Mob: 0410 437854 >>> >>> On 22 Mar 2021, at 8:45 pm, David Chadwick <D.W.Chadwick@kent.ac.uk> >>> wrote: >>> >>> >>> >>> Hi Drummond >>> >>> thankyou for the clarification. We could also state that the converse is >>> also true >>> >>> a. An SSI system shall not require reliance on a blockchain or other DLT >>> >>> but of course it may include them. >>> >>> Note that the W3C VC Data Model already states that VCs do not depend on >>> DIDs and DIDs do not depend on verifiable credentials, so we do not need to >>> include that in your principles. >>> >>> However, can you tell me how principle 11 >>> >>> *An SSI ecosystem shall empower identity rights holders to protect the >>> privacy of their digital identity data and to share the minimum digital >>> identity data required for any particular interaction.* >>> >>> can be supported by long lived VCs that have a persistent DID for the >>> subject ID, when this is a correlating handle that does the opposite of >>> protecting the privacy of the data subject >>> >>> Kind regards >>> >>> David >>> >>> >>> On 22/03/2021 01:55, Drummond Reed wrote: >>> >>> David, I believe you're misinterpreting the third principle. It doesn't >>> say that centralized systems can't be involved or can't issue a VC. It says >>> only that an SSI ecosystem cannot make a centralized system the only option >>> for representing, controlling, or verifying identity data (which is the >>> case with centralized or federated identity systems). >>> >>> BTW, just to clarify, it also doesn't mean an SSI ecosystem can't >>> *include* centralized or federated identity systems as a subset of the >>> SSI ecosystem. Again, it just means that the centralized or federation >>> systems can't be the only option. >>> >>> =Drummond >>> >>> On Sun, Mar 21, 2021 at 4:36 AM David Chadwick <D.W.Chadwick@kent.ac.uk> >>> wrote: >>> >>>> Hi Steve >>>> >>>> I think you will have a hard time convincing anyone of the principles >>>> of SSI when Sovrin's third principle states >>>> >>>> 3. An SSI ecosystem shall not require reliance on a centralized system >>>> to represent, control, or verify an entity’s digital identity data. >>>> >>>> This is clearly impossible, since every VC Issuer that I know has a >>>> centralised system in which they store, manage and update the user's PII >>>> from which they issue their VCs. >>>> >>>> Kind regards >>>> >>>> David >>>> >>>> >>>> On 20/03/2021 20:25, Steve Capell wrote: >>>> >>>> Hi Michael >>>> >>>> As a contractor to Australian government I deal with policy makers >>>> almost every day and so I understand both the difficulty and the necessity >>>> of conveying these concepts to non technical audiences. >>>> >>>> As a sufficiently technical reader, I liked your article. It’s the >>>> first time I’ve seen that meta-model of the identity domain and, for me, it >>>> was very helpful. >>>> >>>> However, sadly, I don’t think it will help the policy maker that is not >>>> used to reading meta models. I usually have more success with storyboards >>>> that contrast two architectures with real examples. Policy makers don’t >>>> need to “understand the architecture”. They need to be able to >>>> conceptualise how it works through examples to that they can understand the >>>> policy impacts and opportunities. >>>> >>>> I also need to convey these ideas - both to AU and UN sometime over the >>>> next month or so. I’ll need to test my communication materials on non >>>> technical people to ensure the message has worked - and also on expert SSI >>>> community members to ensure that the message is right. For that latter >>>> concern, please let me know if anyone in this group is willing to be a >>>> sounding board >>>> >>>> Kind regards >>>> >>>> Steven Capell >>>> Mob: 0410 437854 >>>> >>>> On 21 Mar 2021, at 4:47 am, Michael Herman (Trusted Digital Web) >>>> <mwherman@parallelspace.net> <mwherman@parallelspace.net> wrote: >>>> >>>> >>>> >>>> RE: In prep calls for the panel and other mentions of our work, the >>>> “Self-Sovereign Identity” concept is treated as controversial. In a recent >>>> major webinar about mandated protocols by the US regulators themselves, >>>> they referred to “Distributed Identity”. >>>> >>>> >>>> >>>> I’m trying to address the same issue wrt what is “Self-Sovereign >>>> Identity” / “SSI” at its very core. >>>> >>>> >>>> >>>> Check out: >>>> https://hyperonomy.com/2021/02/01/ssi-unconscious-contractions/ >>>> >>>> >>>> >>>> I’m looking for additional people who share a similar perspective. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Michael >>>> >>>> >>>> >>>> *From:* Adrian Gropper <agropper@healthurl.com> >>>> <agropper@healthurl.com> >>>> *Sent:* March 20, 2021 8:58 AM >>>> *To:* Manu Sporny <msporny@digitalbazaar.com> >>>> <msporny@digitalbazaar.com> >>>> *Cc:* W3C Credentials CG <public-credentials@w3.org> >>>> <public-credentials@w3.org> >>>> *Subject:* The SSI protocols challenge [Was]: W3C DID Core 1.0 enters >>>> Candidate Recommendation stage >>>> >>>> >>>> >>>> It is indeed a big deal and cause for celebration. >>>> >>>> >>>> >>>> From my perspective the next challenge is to get the protocols right >>>> from a human-centered and community perspective. >>>> >>>> >>>> >>>> For an example of that challenge, on March 30 I’m on a Digital >>>> Credentials panel at the ONC (US Federal healthcare regulator) Annual >>>> Meeting. In prep calls for the panel and other mentions of our work, the >>>> “Self Sovereign Identity” concept is treated as controversial. In a recent >>>> major webinar about mandated protocols by the US regulators themselves, >>>> they referred to “Distributed Identity” :-? >>>> >>>> >>>> >>>> Let us celebrate and consider the Fun times ahead.... >>>> >>>> >>>> >>>> Adrian >>>> >>>> >>>> >>>> On Sat, Mar 20, 2021 at 10:16 AM Manu Sporny <msporny@digitalbazaar.com> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> Decentralized Identifiers (DIDs) v1.0 has reached the Candidate >>>> Recommendation >>>> stage at W3C. The current specification can be found here: >>>> >>>> https://www.w3.org/TR/2021/CR-did-core-20210318/ >>>> >>>> This is a major milestone in the W3C global standards process. It marks >>>> the >>>> start of a period of 1-4 months where the official W3C Working Group has >>>> communicated that it is done with all features in the specification. >>>> >>>> The W3C DID WG has also communicated that the specification is stable >>>> enough >>>> to collect implementation experience from the global implementer >>>> community. >>>> Once the WG collects enough implementation experience, it may then make >>>> final >>>> adjustments before publishing the v1.0 global standard, which is >>>> expected at >>>> the end of September 2021. >>>> >>>> I have attached an image with an (unofficial) graphical depiction of >>>> the DID >>>> standards history and expected future timeline. >>>> >>>> Congratulations to everyone that contributed to get us to this point; >>>> this is >>>> a big deal and cause for celebration. :) >>>> >>>> -- manu >>>> >>>> -- >>>> Manu Sporny - https://www.linkedin.com/in/manusporny/ >>>> Founder/CEO - Digital Bazaar, Inc. >>>> blog: Veres One Decentralized Identifier Blockchain Launches >>>> https://tinyurl.com/veres-one-launches >>>> >>>>
Received on Monday, 22 March 2021 13:08:42 UTC