DID Usage - new did property or allow DIDs be used as the sub

[AdamJLemmon]

@tplooker We have tended to note that the sub field be a cryptographically verifiable URI.
Where a DID would fall into that category, so have generally be specifying DIDs directly as the sub.
Not using a separate property if a DID is used

sub: A crypto verifiable URI, ie. DID, urn:uuid generated from jkt... etc.

What do you think?

[dwaite]

Four comments - I have been trying to hold back feedback for public review but I can't anymore :-)

1. A sub is already declared to be either a string or a fully-formed URI, differentiated on containing a colon character
2. There is reason to not have sub at all for privacy. There is also no guarantee a process for doing cryptographic verification of representation is defined for a URI scheme (heck, it isn't even for did).
3. There is no reason for did-specific metadata here, for instance the subject_types_supported array can be extended to enumerate supported URI schemes and partial did paths. (since there is no URI term for what DIDs do with DID methods). DIDs may provide an easier path for declaring how to achieve interoperable verification for identifiers.
4. A substantial portion of this is likely better defined in a portable identifier spec, not a credential retrieval spec. This could be a cross-cutting concern for both credential issuance and presentation, as well as for the id_token.

[alenhorvat]

Since did is a URI there's no need for an additional claim did (in all our cases, so far, we're passing did via sub)

@AdamJLemmon can you define or point to a reference about the "cryptographically verifiable URI"?

The DID Document may be cryptographically verifiable (for some methods), however, DID can be just a random string (not generated from any DID key, DID Document, ...). You can validate that the DID is registered in a specific registry and you can validate the connection between a DID document and the DID.

did_methods_supported
Do we need this in order to learn if the credential issuer can validate the DID/DID Document?
If yes, this may or may not be enough, as DID Document can contain a very wide range of different types of keys (RSA, EC, ...).
DID resolution can be done, for most methods, via the Universal Resolver. Would this be enough or should the CI/CH be able to perform full DID Document validation?