did:web based Identifier for an Issuer, Holder/Subject, Verifier - What is In Scope / Out of Scope or Appropriate / Not Appropriate?

[aniltj]

The use of did:web based identifiers assigned to Authoritative Issuers (especially when the issuer is a Sovereign which needs to be public and transparent and visible in identifying itself in digital transactions) such that they can bootstrap from existing infrastructure they already own, operate and trust (DNS and Web) looks to be important for both adoption as well as legitimacy and transparency i.e. Authoritative issuers of credentials and attestations should not, and do not have the luxury of hiding behind pseudonymous or anonymous identifiers; they need to be visible to be held accountable.

However, there may be potential privacy/tracking/correlation concerns in using the did:web method to assign a DID to a holder/subject or a verifier (when that verifier is a person and not an organization).

Does it make sense to limit and constrain the use of did:web to Non-Person Entities (NPEs) i.e. Organizations, Devices etc. ONLY given the ability of an organization to assert control over their Web and DNS infrastructure, and deliberately make the use of did:web for use as an identifier for a person to be out of scope?

[OR13]

I don't think it makes sense to constrain the domain of the did subject, in ANY DID Method :)

In the DID WG we are debating the type property of DID Subjects, but regardless of what the WG decides, RDF will retain support for id and type... removing type would be like removing numbers from javascript.

Establishing conventions that enable privacy, or that impact laws is not the job of DID Methods, it is the job of governance frameworks, and governments :)

In other words, our job as DID Method authors is to make the best printing press, it's not our job to decide what kind of material is printed.

That being said, each did method does have security / privacy trade offs... some DID Methods are susceptible to legal coercion, that might exclude certain types of subjects. Any permissioned system will in general be weaker in this regard, since the adversary (which may be a nation state actor) can attack subjects by any authority they rely on, such as DNS, or a permissioned ledger.

This is the kind of thing that belongs in the privacy and security considerations section of the DID Method spec.

[aniltj]

This perspective is familiar and prevalent in our technical community >> "We just want to build the best stuff with the best of intentions for others to use. Nothing more and nothing less."

I happen to disagree with this perspective as I believe it is incumbent on technologists to consider the consequences (use, misuse and abuse) of what they build and bake in appropriate mitigations and counter-measures up front to potential misuse and abuse instead of leaving it up to some other party.

Be that as it may be, it sounds like this spec needs a very hefty Privacy and Security considerations section at a minimum. However, I am hoping that there is something more concrete that can be done here.

[OR13]

@aniltj this isn't malware security research :) we are applying RDF to expressing cryptographic concepts, if we start applying restrictions to RDF because of an assumed domain, we will inevitably pull in politics into what should have remained a purely informational modeling discussion...

I'm not saying there is no place for that discussion, I'm saying that its a poor separation of concerns to conflate "human values" and "capabilities"... for a clear example of this, see "Smart Guns" and "Biometric Gun Safety"....

From an engineering perspective, the development of biometric authenticators and firearms is fine... requiring that they are always combined causes serious problems, essentially eliminating features needlessly, for example the ability to delegate and the ability to NOT delegate cannot co-exist...

similarly WRT type... in an open world model, there are infinite possible type values that might be related to a person... so adding such a restriction leads to a closed world data modeling environment... it starts us down a path of an ever growing deny-list which is an anti-pattern in information security.

We do have a number of PRs and issues already opened related to privacy / security of this method, I think we will be able to add the necessary guidance without needing to limit functionality :)

[OR13]

I suggest we restructure this issue as:

Privacy & Security Section has been reviewed / approved by an independent 3rd party

and then we ensure we have made the necessary changes needed to support that review.

[msporny]

I don't think it makes sense to constrain the domain of the did subject, in ANY DID Method

Sorry, strong -1 on this. There are some DID Methods that are dangerous, and did:web is one of them. So much damage has been done by the tech industry to individual privacy under the guise of "it's not our place to take a position on this". On the Internet, code is law.

did:web suffers from the "phone home problem". We already know that did:web would be a privacy disaster in the hands of companies that benefit from surveillance capitalism. It enables the worst sort of individual/citizen tracking (tracking without opting in and without collusion). We should unequivocally state that in the specification. Even private corporations would probably not want to use it because it allows other organizations to track their movements online, many of which might be considered a trade secret.

There are only a handful of scenarios where it's safe to use did:web:

• You are a public organization or government announcing your DID via your domain (e.g., Microsoft, DHS CBP, etc.).
• You own the did:web domain on which your DID is registered (e.g., personal website).

... every other use of did:web should be suspect and requires careful scrutiny and use (by people that know what they're doing). The specification should be crystal clear on this -- it is not safe for general use, you will be tracked. There should be clear guidance against issuing VCs to did:web by organizations as they would be helping to create a surveillance network on private individuals and organizations.

[peacekeeper]

The way I would put it is that neither the method name, nor the method-specific identifier, nor the basic DID CRUD operations should say anything about the type of the DID subject (person, organization, etc.). Those parts of a DID method should only establish how it works technically. At some point there were proposals that the DID method name itself could restrict what the DIDs identify (e.g. see here), which I think is not a good idea.

So on the technical level, there should be nothing that constrains what the DID identifies (maybe this is what Orie is saying).

At the same time, I agree with Manu and Anil that certain DID methods such as did:web can be dangerous if used for individuals. I do think it's a good idea to strongly mention this in either the non-technical sections (privacy) of a DID method spec, and/or in governance/trust frameworks where those DID methods are used.

[OR13]

So am I correct in stating that it's OK for you to use did:web if you own the domain, for both issuer and subject roles in a VC?

And its dangerous for you to use did:web as issuer or subject if you don't own the domain?

Isn't this sorta similar to how not running a blockchain node and relying on someone who does reveals some activity to that service provider?

Comparing did:web:facebook:user123 to "sign in with facebook" what additional privacy issues exist?

[gribneau]

The set of safe use cases above is incomplete.

DID:WEB is an explicitly public identity, and can be seen as analogous to any other publicly visible identity. Generally speaking, social media usernames are public identities, some of which also export public keys.

As an example this site exposes the public keys a user has registered with it.

curl https://github.com/<username>.keys

I do support adding language to make it explicit that this standard should be used only in cases where the user fully intends to expose an identity to the public.

I do not, however, support preventing individual use. Individuals may very well intend to create and use a public identity.