- From: Jeremy Townson <jeremy.townson@gmail.com>
- Date: Mon, 22 Mar 2021 12:06:30 +0000
- To: Steve Capell <steve.capell@gmail.com>
- Cc: David Chadwick <D.W.Chadwick@kent.ac.uk>, drummond.reed@evernym.com, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAAic94FGcDS8BahhHUAmb=PyGQVwhxscAzZStqSSpe3fgg8T3g@mail.gmail.com>
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 12:06:55 UTC