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

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> 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>
Sent: March 20, 2021 8:58 AM
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C Credentials CG <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