Ability for DID in a Method to be known as more than one ID, with a canonical selection

[csuwildcat]

Is there an existing, standard mechanism that allows a DID Method to express that two DIDs in its system are provably, deterministically the same? For example: Say you have one representation of the DID that is 1000 characters long, and another that is the hash of that 1000 characters. These are provably the same in the target system, so is there a way to disclose the hashed version and the 1000 character version are the same DID? If not, could we add a property like canonical so a DID Method can stipulate this in the returned DID Document?

[OR13]

@talltree @dmitrizagidulin @msporny I suppose this a variation on the question of sameSubject vs alsoKnownAs....

the short answer for me is that sameAs was created to do exactly this....

#33
w3c-ccg/security-vocab#45
w3c/did-extensions#80

Knowing your use case.... I don't see any reason why anyone would object to:

shortFormDID sameAs longFormDID

but clearly @msporny and others are concerned about the security implications of RDF statements.... see the issues linked.

[peacekeeper]

I agree with @OR13 that this would probably be done with the new "same" property (whatever its name will be in the end).

Some DID methods will allow the controller to put these "same" properties into the DID document however they want. Other DID methods such as the one proposed here will have this property "built-into" their DID documents.

[csuwildcat]

@peacekeeper I am having a hard time with the 'same' definition, because what I am really seeking is a way to express "If a canonical property/value is not present, use the version of the identifier you used to resolve this document, but if the canonical property/value is present, you SHOULD use that identifier instead from here forward." Same seems to indicate that they are interchangeable, but what I want is unidirectionality and for people to cease use of the longer form of the ID if there is a shorter canonical one present in the DID Document. Can you help me understand how this would be achieved in a normative way across all DID Methods using 'same'? My goal is for there to be no ambiguity about the directionality, and have it be a generally understood paradigm.

[OR13]

@csuwildcat sounds like you are looking for https://www.w3.org/OWL/#:~:text=The%20W3C%20Web%20Ontology%20Language,things%2C%20and%20relations%20between%20things.

Want to describe how things are related using an international standard.... and not reinvent the wheel?

sameAs is one OWL relation.... there are others.

[csuwildcat]

@OR13 admittedly, I could be more familiar with OWL, but to fast forward to the right answer, can someone on this thread link me to an existing spec or property we can use that means the thing I am saying: a unidirectional canonical pointer to a preferred form of an equivalent ID?

[OR13]

https://www.w3.org/TR/owl-ref/#sameAs-def

thing1 sameAs thing2

QED. :)

You tell me if that defintion doesn't work for you, the burden is now on you to provide a stronger normative definition.... or you can invent a new one...

[OR13]

Possibly better solution:

https://www.iana.org/assignments/link-relations/link-relations.xhtml

relCannonical

https://tools.ietf.org/html/rfc6596

possible solution https://www.w3.org/2005/05/hrel/

[peacekeeper]

The ongoing discussion around sameAs, alsoKnownAs, sameSubject carries only semantics of equivalence, but those properties don't express that one identifier is "canonical" or "preferred" over the others, which is what @csuwildcat wants here.

Based on what @OR13 found above, it seems we could "RDFize" the canonical link relation, e.g. we could add the following to our JSON-LD context:

{
  "@context": {
    "@version": 1.1,
    "id": "@id",
    "type": "@type",
    "lt": "http://www.w3.org/2002/06/xhtml2/",
    "canonical": {
      "@id": "lt:canonical",
      "@type": "@id"
    },
    ....
}

And then a DID document could look like this:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:1234",
  "canonical": "did:example:abcd",
  "authentication": [{
    ....
  }],
  "service": [{
    ....
  }]
}

Pros: Re-using existing concepts. Alignment with Web Linking (RFC8288) philosophy.
Cons: Would this introduce a weird dependency on XHTML that we don't want? Is there a more "modern" way of doing this in Linked Data?

[OR13]

ping @philarcher @msporny @dlongley how do you feel about canonical?

[msporny]

how do you feel about canonical?

It kinda fails the "plain english" test --

https://www.merriam-webster.com/dictionary/canonical

https://www.dictionary.com/browse/canonical

https://dictionary.cambridge.org/us/dictionary/english/canonical

A non-trivial subset of people reading "canonical" might be confused... we're maybe meaning it in the mathematical sense, but even there, it's wrong. The identifier isn't a canonical mathematical form... it's a preferred alias.

We could do preferredId to express that the DID Subject prefers a particular ID. Keep in mind that this is subtly different from sameAs, which is bi-directional. It's probably closer to the use case people want to solve, but again, I'm still waiting for people to write down all the use cases we're trying to address. If all we're trying to do here is address @csuwildcat's use case, then yeah... we want a directional relationship that expresses a preference of one identifier over another. Thus:

<did:ex:1234> preferredId <did:ex:5678> .

If people are fine to leave the sameAs use case behind and what folks have really been talking about is the above, then preferredId is closer to plain english, expresses a unidirectional relationship, and is specific to DID Documents (for now), which addresses the security concerns raised when we were discussing a bidirectional relationship property.

[philarcher]

This thread is conflating two separate issues. Any given subject can have any number of identifiers and they may well be related by owl:sameAs or some other relationship. That's not the same as "if I can choose between 2 IDs for the same thing, which one is 'best'? The origin of the canonical URL is in search engines looking for the one URL they should index given n possibilities since things like tracking IDs create multiple URLs for the same thing.

But even that isn't what I understand @csuwildcat to be asking.

You can hash anything, and hashing a URI is not a new idea. See, for example, this from 2002. In my work at GS1 we set out how to mint a URI that identifies an item, and there can be any number of them that identify the same thing (we allow any domain name, we allow '01' and 'gtin' as synonymous path elements etc.)

We do then define a one way algorithm for creating the canonical URI that identifies the item. It's very GS1-specific but it includes:

• specifying a given domain name
• using the numeric form of the ID keys
• a future version is expected to include alphabetizing the query string
  (see page 33 of the GS1 Digital Link spec)

The motivation here is so that there is a single GS1 ID that can be digitally signed.

I think in the current case, a canonical URI is going to be DID method-specific and the method should define what is the canonical URI and how to generate it. If a method wants to say that the short version is the canonical one, OK, do that and make that a property of the DID doc.

[OR13]

agreed...

@msporny I think you forgot to use wikipedia (the one true source of information) :)

https://en.wikipedia.org/wiki/Canonical_link_element

preferredId or canonical are NOT the same as sameAs.... let's not conflate them.... however we can group them all under the term of "linkType" relations.

I think it would be valuable for DID Core to define normatively some terms with roughly the following definitions:

Term1 (sameAs)

Term1 MUST be an IRI or array of IRIs. Term1 is used to specify that the DID Subject is also identified by the value(s) of Term1, and that the DID Controller has no preference for which identifier should be used for the DID Subject.

Term2 (canonical)

Term2 MUST be an IRI. Term2 is used to specify that the DID Subject is also identified by the value of Term2, and that the DID Method prefers for the value of Term2 to be used to identify the DID Subject.

I am, hopefully unsurprisingly at this point, not in favor of creating additional redundant terms in this specification when well specified vocabulary exists which is directly relevant to the task at hand....

@msporny Does any of this discussion change your mind w3c/json-ld-api#139 (comment) ? it seems some of this was addressed in JSON-LD previously, and as others have noted... its a very common web standards thing to need...

Consider a case where someone invents a variant of did:key, but wishes to specific that the canonical IRI for the did subject should be the vanilla did:key... for example:

did:key:1?transform-jwk canonical did:key:1.... how would you prefer the did document convey the preference for the did subject identifier?

[csuwildcat]

The most familiar definition for the word canonical that devs will be familiar with is the one from the HTML spec, as it pertains to link relationship types: "canonical - Preferred URL for the current document". For this reason, I feel it is the best choice for this property name.

[csuwildcat]

Resolved by latest PR for id prop usage clarification.

[OR13]

related: #421

[csuwildcat]

Reopened, as it's still not resolved.

[msporny]

This is on the agenda of an upcoming virtual face-to-face meeting.

[peacekeeper]

My understanding is that this would be addressed by #431, so I'm marking this as "PR exists".

[peacekeeper]

We discussed this issue during the 2020-11-19 DID WG Topic Call.

[msporny]

This issue will be addressed by PR #431 and will be closed once that is merged.

[msporny]

PR #431 has been merged via PR #473; closing.