Re: The SSI protocols challenge [Was]: W3C DID Core 1.0 enters Candidate Recommendation stage

On Mon, Mar 22, 2021 at 1:28 PM Drummond Reed <drummond.reed@evernym.com>
wrote:

> Inline.
>
>> 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
>>
> David, I fully agree with you, which is why privacy-preserving VCs should
> not be issued to persistent DIDs. They should be issued to blinded link
> secrets using zero-knowledge proofs. This way you not only avoid identifier
> correlation, you avoid signature correlation.
>
> Of course neither can prevent correlation in the verifier requires that
> the holder reveal a correlating identifier, such as a government ID number,
> but at least that is *intentional* and *explicit* correlation, not
> unintentional implicit correlation using the underly VC mechanics.
>

While this is obviously a point of debate in this group still, I'll state
my viewpoint:

DIDs identify a DID subject, which is an entity/concept correlated within a
particular context. This is not different from other cases where an
identifier represents a subject. Hence public (no limit to correlation) or
pairwise/n-wise (used within a limited context with others). A DID can
leave this context, but there won't be an opportunity for other parties to
correlate new information with it. In other words, a DID represents an
entity's persona.

The two most interesting properties of DIDs to me are:
1. A DID abstracts away various properties behind the method resolution
step, so a system that normally just needs pairwise transient identifiers
can still support use of public, persistent identifiers.
2. Likewise, the DID method abstracts away the persistence infrastructure
(I look at DLTs as being another variety of data hosting infrastructure).
Existing identity systems tend to require an investment in infrastructure
(DNS name, HTTPS addressability) to become an issuer.

(Obviously, this abstraction did not actually solve the problem of needing
to support the actual resolution process. A DID method that entities within
a context refuse to support is effectively unusable)

With respect to VCs and DIDs
1. In most current trust systems, the issuer of a VC needs to have identity
to evaluate credential trust. VCs allow any identifier to be used here,
including DIDs.
2. There are cases where the identity of the subject has a public persona -
in this case it makes sense to refer to the subject using a public
identifier, which could include a DID. The expectation should be of
correlation as part of building a reputation with that public persona. A VC
that a subject shares about their public persona will almost always be a
positive influence on that reputation (or else why did they choose to share
it)
3. Selective disclosure of attributes means that one or identifiers could
be included for optional disclosure - meaning that a VC could be
potentially used across multiple personas.
4. Issuing credentials to a subject represented by identifiers necessitates
that the issuer be a part of the context of that identifier, and
thus allows for the issuer and verifier to potentially correlate and
communicate about the subject

Selective disclosure formats in many cases have their own method of
authenticating the subject of the message, and do not rely on or leverage
identifiers for that purpose. Linked secrets is one common example in
attribute-based encryption systems, while a system which uses one-time-use
credentials may rely on ephemeral keys.

A DID subject for a long-lived credential has dubious value when not
attempting to represent a subject's persona. One often quoted ability is
for the subject to dynamically update a DID document with new verification
methods for cryptographic hygiene or entirely new methods re: post quantum,
without needing to coordinate with the issuer. However, the issuer also has
these same needs, which implies that the credential will expire (or be
revoked). To get a new credential, the subject will still need to maintain
a relationship/process with the issuer. A subject using DIDs can
independently update their verification method, but having better crypto
hygiene than your issuer doesn't necessarily provide value within the
context of the VC - it only provides value to increasing the integrity of
the persona.

IMHO, wallets would be better served to focus on maintaining issuer
relationships for (re-)acquiring credentials, vs trying to maintain a large
set of pairwise persistent DIDs or pushing subjects toward creating shared
personas in order to leverage DIDs.

-DW

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._