Current language around equivalent canonical DIDs increases signature verification complexity

[tplooker]

Problem

As per PR which introduced the note in section 5.1 around intermediate representations now allowing the id to be populated with an equivalent canonical DID. This appears to have created some problematic cases that will increase the complexity around verifying digital signatures that involve DIDs making use of this feature.

For context, in this issue I am going to make things concrete with an example based on how sidetree intends to use the feature to convey the problem.

A Sidetree did has two canonical forms

1. A long form (where the method specific id is essentially the initial encoded state of the did document)
2. A short form (where the method specific id is essentially a hash of the initial encoded state of the did document)

The current behaviour around resolution making use of the newly added note, leads to the following

Resolving a long form ID where the did is un-anchored resolve(did:ion:<long-form-id>)

Will yield the following response

{
  "id":"did:ion:test:<long-form-id>",
  "@context":["https://www.w3.org/ns/did/v1"]
}

Where as resolving a long form ID where the did is anchored resolve(did:ion:test:<long-form-id>)

Will yield the following response, note the short form ID is present instead of the long form ID.

{
  "id":"did:ion:test:<short-form-id>",
  "@context":["https://www.w3.org/ns/did/v1"]
}

The above behaviour is potentially problematic when verifying certain digital signatures that makes use of DID's such as linked data proofs, as today much of the infrastructure assumes that the resolved document id matches that of the id used in the resolution request.

To make things concrete take the following example using VC's

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://example.edu/credentials/1872",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "issuer": "did:ion:test:<long-form-id>",
    "issuanceDate": "2010-01-01T19:73:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": "Example University"
      }
    },
    "proof": {
      "type": "RsaSignature2018",
      "created": "2017-06-18T21:19:10Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "did:ion:test:<long-form-id>#key-1",
      "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
        sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
        X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
        PAYuNzVBAh4vGHSrQyHUdBBPM"
    }
}

If resolving did:ion:test:<long-form-id> returns a did document with did:ion:test:<short-form-id> as the ID, and further more, forms the base URI for the rest of the DID document, signature verification with many current implementations would fail.

Proposal

Restore the restriction that the id in the resolved did document must match that used in the resolution request AND if there is a canonical or preferred alternative DID that is available (logic defined by the did method) then it should instead appear in a seperate property in the did document called preferredDid, meaning the example provided above would change to

Resolving a long form ID where the did is anchored resolve(did:ion:test:<long-form-id>)

Will yield the following response.

{
  "id":"did:ion:test:<long-form-id>",
  "preferedDid": "did:ion:test:<short-form-id>",
  "@context":["https://www.w3.org/ns/did/v1"]
}

[kdenhartog]

This aligns with some of the comments I saw during the normative statements review document. Making this change will be incredible beneficial to the uncertainty that was added to those normative statements. I'm in favor of changing the normative statement from:

The value of id in the resolved DID document MUST match the DID that was resolved, or be populated with the equivalent canonical DID specified by the DID method, which SHOULD be used by the resolving party going forward.

to

The value of id in the resolved DID document MUST match the DID that was resolved.

[peacekeeper]

I always felt uncomfortable about allowing the id to contain anything other than the original DID that was resolved, so I'm in favor of changing it back.

An alternative to prefer(r)edDid in the DID document could also be to use a DID resolution metadata property, as I mentioned here https://github.com/w3c/did-core/pull/376#issuecomment-680286809, but the above also seems reasonable and perhaps simpler than using metadata.

[csuwildcat]

Proposal for a definition of the preferredDid property:

The preferredDid property MAY be present in a DID Document, and if present its value MUST be a DID URI string specified by the DID Method as the equivalent canonical DID which SHOULD be used by the resolving party going forward.

[tplooker]

+1 to @kdenhartog suggested revision to the definition for id.

+1 to @peacekeeper suggestion around spelling preferred right too :)

w.r.t whether the property should exist in the resolution meta-data or the actual did document, I can see an argument being made either way but am personally leaning towards it being a property of the did document.

[csuwildcat]

w.r.t whether the property should exist in the resolution meta-data or the actual did document, I can see an argument being made either way but am personally leaning towards it being a property of the did document.

My argument for it being in the DID Doc is primarily based on two key points:

1. Given this property represents the singular, logical DID in the target system, and is issuing an important directive about the DID in the id property, it doesn't feel like some sort of addendum/note about the resolution, thus I think metadata isn't the best place for it
2. Given alsoKnownAs is already a property in the DID Doc that describes a form of equivalent DID, and this is another form of equivalent DID, albeit a stronger, more concrete form, it would be strange to have one equivalence property in the DID Doc and one randomly hanging out in metadata. To be consistent, I think it makes sense to have them both located in the DID Doc.

[OR13]

agree with the proposal, not a big fan of the term preferedDid, bikeshedding the property:

consider the triples:

• did:example:123 betterKnownAs did:example:456
• did:example:123 preferredToBeKnownAs did:example:456 <- my favorite so far.
• did:example:123 preferredId did:example:456
• did:example:123 preferred did:example:456
• did:example:123 canonical did:example:456
• did:example:123 useCanonical did:example:456
• did:example:123 authoritative did:example:456
• did:example:123 useInstead did:example:456
• did:example:123 nextId did:example:456
• did:example:123 recommended did:example:456
• did:example:123 sameAs did:example:456

[tplooker]

Since we are picking colours for the bikeshed :)

• did:example:123 canonicalId did:example:456
• did:example:123 canonicalDid did:example:456

[csuwildcat]

Of the options, my first preference is canonicalId, but some folks have said they don't think canonical is a good term (despite it being the common term in URL referenced resources since the birth of the web). My other preferred options are recommendedId and preferredId.

[peacekeeper]

I think the value should be allowed to be any URI, not just DID, to be consistent with alsoKnownAs (although we may want to add a note/warning about the consequences of using a non-DID URI).

[troyronda]

+1 to @csuwildcat - the property belongs in the DID document.

[OR13]

I'm a fan of canonicalId or preferredId or recommendedId.

[csuwildcat]

@dlongley can you chime in to make sure we've settled on the right terminology? I chatted with Manu, Drummond, and others and they were good with this (sans whatever property name we choose)

[dlongley]

First, I'd like there to be a solution to the problem here. I'm onboard for helping where I can to find a good one.

Second, however, I'm not sure this won't be trading one problem for another. Can someone explain how this will work when resolving the shortform version? If I see a "verificationMethod": "did:ion:test:<short-form-id>#key-1" in a proof ... what will happen when I try to resolve that? Will the DID Document have the long form in id or the short form? It seems like we'd be back to having the same problem in reverse if it didn't use the short form. In this case, we're really just talking about having two different DIDs and two different DID Documents.

Does special software have to be written to consider preferredId and use it properly? If so, do we even need the property? Why wouldn't the special software that understands the ion method just hash the long form and offer it up as the preferred ID for use? In that light, it seems to be a function of the DID method; it doesn't have to do with the DID subject announcing something for applications to act on. Or is the goal here to make it so that software will always use the value of preferredId instead (regardless of DID method)? Can we make this non-method specific? Is there a pattern or understanding here that wouldn't feel so ion-specific so we could accomplish that? I think it would be much better for ion if special code weren't needed.

How will the verification method IDs appear in the DID Document? If there are two DID Documents (a long form one and a short form one), then I think the answer to that is more straightforward, i.e., getting a DID via ion should just be thought of as always getting two DIDs at once. Each DID resolves to its own DID Document and the short form one doesn't do any of this preferredId stuff. Then, what happens with ion could be mapped to a similar situation with any other DID method that wants to allows users to announce a different DID that should be migrated to. That feels more naturally like something a DID controller may do on behalf of the subject.

From this perspective, perhaps "preferredId" is not a strong enough name. Perhaps we want something that's more like a permanent redirect. Of course, this would have to be more like a "permanent redirect, if it exists" since I presume "preferredId" would appear in the long form DID Document. It's also a bit weird to make that statement about the DID subject, which may have multiple DIDs (with different methods) that refer to it -- which should be preferred? This points to it being a resolution thing as it seems to relate to the DID method rather than the DID subject.

Is there way to do this elegantly such that if you try to resolve the long form DID, you get a DID Document with the long form in it -- but the metadata may say "permanent redirect" for when the short form DID is available on ledger ... and make it so that did:ion resolvers can automatically follow that redirect? That way, when you plug in a did:ion driver into a DID resolver library, it would follow the redirection and set the proper base URI and so on?

Does this still cause the verification problems alluded to here? I suppose the problems may be caused by an attempt to do automated redirection instead of just surfacing this extra value that may optionally be used. But that doesn't seem to address the "ion is special" case -- I think it would be better if it didn't need special treatment, as it will harm adoption.

Can we have a more concrete example of existing verification code and where it fails -- so we can analyze potential solutions?

[csuwildcat]

Can someone explain how this will work when resolving the shortform version? If I see a "verificationMethod": "did:ion:test:#key-1" in a proof ... what will happen when I try to resolve that? Will the DID Document have the long form in id or the short form?

The spec text would be restored to state that you MUST always have the same DID in the id field that was resolved. This is about another property that is used to express an equivalent alias for the same logical ID in the system, and we would be breaking it out of the id prop, the same way alsoKnownAs is.

It seems like we'd be back to having the same problem in reverse if it didn't use the short form. In this case, we're really just talking about having two different DIDs and two different DID Documents.

Not sure how - this is just about one logical DID, and you would see in id whatever ID you resolved, and include a separate property for an equivalent alias of the same logical ID in the system.

Why wouldn't the special software that understands the ion method just hash the long form and offer it up as the preferred ID for use?

But that doesn't seem to address the "ion is special" case -- I think it would be better if it didn't need special treatment, as it will harm adoption.

I just want to clarify that Sidetree is not special case: any implementation of DIDs that is strongly decentralized (like, come-and-take-my-Bitcoin-from-my-cold-dead-hands decentralized) will have a consensus delay before propagation. As a rule of thumb in decentralized consensus systems: if it's really fast to generate and propagate an L1 transaction (as in a couple seconds or less), it's probably not truly decentralized, and someone is slapping a on a "Decentralized!" sticker to sell a bill of goods.

Is there way to do this elegantly such that if you try to resolve the long form DID, you get a DID Document with the long form in it -- but the metadata may say "permanent redirect" for when the short form DID is available on ledger ... and make it so that did:ion resolvers can automatically follow that redirect? That way, when you plug in a did:ion driver into a DID resolver library, it would follow the redirection and set the proper base URI and so on?

^ This is more or less what this proposal is doing, but I think the existing language around the id property may be getting in the way here - to be clear: we are talking about the very type of separation you are alluding to.

[dlongley]

@csuwildcat,

Not sure how - this is one DID, the DID you resolve, which includes within it a property for an equivalent alias for the same logical ID in the system, this it includes that alias of the same logical DID in the DID Document.

If I do resolve("did:ion:test:<short-form-id>") what comes back in the DID Document's id field?

[csuwildcat]

If I do resolve("did:ion:test:") what comes back in the DID Document's id field?

Whatever ID you resolve would come back in the id field - in this case, that's the short-form, because that's the one you resolved. But if the Method determines there is an equivalent alias for the same logical ID in the system, that may be present in this field we're talking about splitting out (after we restore the previous spec text for the id property).

[dlongley]

@csuwildcat,

I just want to clarify that Sidetree is not special case: any implementation of DIDs that is strongly decentralized (like, come-and-take-my-Bitcoin-from-my-cold-dead hands decentralized) will have a consensus delay before propagation.

Veres One solves the problem differently. It requires that the DID itself include the public key fingerprint for its capability invocation key (the same key used to perform an action to register with the ledger). The resolution rules still resolve a Veres One DID whether it's on ledger or not, but the DID never changes. The difference is that, only once it's on ledger can you make edits to add additional keys, etc. This avoids the long form/short form problem entirely -- allowing usage of off-ledger or on-ledger DIDs with proof of control, but with the trade off that only on-ledger DIDs support updates and additional information. This approach also bridges the "wait for the ledger to reach consensus" issue.

If Sidetree's use case always involves putting a DID on-ledger, then they may be able to take a similar approach. You can sign VCs before it's on-ledger that will remain valid once it is on-ledger. But if you need to have additional information like extra keys/services prior to the DID hitting the ledger, then you may need something like this other approach we're discussing. Other options involve signing VCs that would express that additional information instead. I just wanted to point out that there are other options for decentralized mechanisms -- it just depends on your constraints.

[dlongley]

@csuwildcat,

Whatever ID you resolve would come back in the id field - in this case, that's the short-form, because that's the one you resolved.

Ok, that's what I meant by having two different DID Documents. That's relevant because I'm trying to see if there's a way to generalize this so it could become a part of DID consuming software vs. special casing it for ion. Another use case would be someone just trying to cause people to migrate from using one DID to a different one (including with a possibly different DID method).

[csuwildcat]

Another use case would be someone just trying to cause people to migrate from using one DID to a different one (including with a possibly different DID method).

^ This is a good point, I wondered the same yesterday.

[csuwildcat]

But if you need to have additional information like extra keys/services prior to the DID hitting the ledger, then you may need something like this other approach we're discussing.

Yeah, this is the case, we want to allow people to have full DID Documents with all features at inception.

[tplooker]

Another use case would be someone just trying to cause people to migrate from using one DID to a different one (including with a possibly different DID method).

I'd like to explore this one more too

[dlongley]

@csuwildcat,

Yeah, this is the case, we want to allow people to have full DID Documents with all features at inception.

This is somewhat related to whether or not the standard practice is for service endpoints to be in DID Documents or if they'd be found elsewhere ... because, if it were the latter, this would be a non-issue, right? Sidetree could take the same approach Veres One uses then. I don't want to bring the "service endpoint in DID Documents" issue into yet another thread, of course, but I do think this was worth mentioning because it's another benefit we would get from the separation of concerns.

However, if we can figure out a way for this to function just like a "migration feature" would, I think that's the way to go. We don't have to debate the above because that sort of feature is useful regardless. I think we should make the solution/language used reflect that.

[tplooker]

@dlongley to an extent, however I would posit that there are other cases where we cannot get away with just one key at the inception for a DID document that does not involve service endpoints. Such as when I as the DID subject would like a DID that features keys that support key agreement and also keys that support bound signatures like a BLS12-381G1 key in BBS+ signatures.

In general what I am saying is that we should not rely on the assumption that a single key at inception style DID is sufficient to cover all use-cases.

[troyronda]

Another use case would be someone just trying to cause people to migrate from using one DID to a different one

We have a use case for a canonical network name along with aliases that can assist in discoverability.

We currently allow DIDs that contain a domain name with .well-known information about the network. This is useful as it allows the DID to also advertise the network discoverability properties.

did:trustbloc:<discovery domain>:suffix

With canonical DIDs (or "migration feature"), we can also effectively "redirect" the resolver to a stable/permanent (canonical) identifier that doesn't depend on a domain.

did:trustbloc:<permanent network identifier>:suffix

An example of a permanent network identifier can be a genesis block hash, configuration hash (or similar).

[csuwildcat]

How does the following spec text sound?

The canonicalId property MAY be present in a DID Document, and if present its value MUST be a DID URI string specified by the DID Method as the equivalent canonical DID. If the DID is resolvable, the resolving party MUST use it going forward, but if the DID is unresolvable the resolving party MUST continue using the DID present in the id property.

[OR13]

If the DID is resolvable, the resolving party MUST use it going forward, but if the DID is unresolvable the resolving party MUST continue using the DID present in the id property.

untestable, suggest deleting.

Suggest:

It is RECOMMENDED that any parties relying the DID Document use the canonicalId, and discontinue any use of the non-canonical identifier.

[dlongley]

canonicalId, as proposed, would be a property of the DID subject, set by the DID controller. It seems a little odd to say Cathy's canonical ID is xyz. I think we have a problem here where we are crossing trust boundaries; if this ID is meant to be a "canonical" representation for a DID, then it should be coming from the DID method and should therefore be meta data. If it is, instead, a feature whereby a DID controller can declare there's another DID they want people to migrate over to when referring to the DID subject, that's different. But this implies we should use a different name from canonicalId for the property.

[OR13]

I agree with @dlongley ... but its not clear who is setting this property, and it is valid for a did controller to use the property... for example:

Alice may want to leave DID Method A, and use DID Method B.... alsoKnownAs, sameAs do not solve this problem, and it is a property that the did controller can set.

If A DID Method is ALWAYS setting this property, then its metadata, and doesn't belong in the did document.... but if a did controller can set it.... I think it's a property of the did subject..... consider a DID Web User, who realizes did:web lacks almost all the security advantages on DIDs... they simply update their DID Document:

did:web:example.com/user/123 canonicalId did:example:456

Now everyone who relied on the did:web sees the controller wants them to use did:example:456 instead.

If the property can be either metadata or a property of the did subject, I suggest we default to "self sovereign / controller" preference over did method reference from a spec interpretation perspective, obviously we can't control what did methods do, but we can guide standard interpretation of a canonical link relation.

[csuwildcat]

@dlongley the intention was not for some random ID assertion to be possible, the intention was to address the case where a DID Method contains multiple DIDs/formulations of the same singular, logical entity/DID within the Method. This property was not supposed to be something a Subject can just set, with it potentially being false or inaccurate, it was supposed to be a deterministic, secure, reliable output of the DID Method.

As of now, we have no way for a DID Document to add any equivalence properties where it, the Method itself, can provide other deterministic DID formulations/entries that are all deterministically known to represent the same entity in the target Method <-- that's what we really want, and it's just as important as other fields where a Subject can paste the DID of the Queen of England, claiming to be the owner. (I would argue even more crucial, because we're talking about securely resolved/populated fields)

There are really two props that would fill this whole:

1. A property that contains a single DID, which is absolutely, deterministically specified by the Method itself to be canonical form of the same DID that was resolved. Let's call this methodCanonicalDID, for descriptive reference during the rest of our conversation.
2. A property where a Method can print out any exactly logically equivalent variants of the same DID that was resolved. Let's call this methodSameAsDIDs, for descriptive reference during the rest of our conversation.

[OR13]

Seems like a method specific extension, if the did method is the only party that injects this property.

I see 2 options:

1. Use an extension (no changed to did core required)
2. Register a new DID Document property canonicalId and specify that ONLY a DID Method may set this value.
3. Register a new DID Document property canonicalId and specify that EITHER a DID Method OR a DID Controller may set this value.

[csuwildcat]

Proposal for an even more 'generic' secureCanonicalId property:

The secureCanonicalId property MAY be present in a DID Document, and if present its value MUST be a DID URI string that is a deterministically provable variant of the ID in the id property. If the DID URI value of the secureCanonicalId is resolvable, the resolving party MUST use it going forward, but if the DID is unresolvable the resolving party MUST continue using the DID present in the id property.

[OR13]

+1 to secureCanonicalId there are lots of DID Methods that would use this, including KERI / Sidetree families.

[csuwildcat]

Two things dawned on me:

1. Canonical switching of IDs is not really what we are after here
2. There is a more general way to address the true need: expressing multiple deterministic variants of an ID

To that end, I believe a deterministicSameAs property (feel free to bikeshed the name) would do a much better job enabling the features/functions we need:

The deterministicSameAs property is an array of one or more DID URI strings that are verified by the DID Method to be deterministically provable variants of the DID in the id property which MAY be included in the DID Document. The resolving party MUST treat the DID in the id property and all DIDs present in the deterministicSameAs array as references to the same logical ID, thus the resolving party MUST retain the DID URIs from the id and deterministicSameAs properties to ensure any subsequent interactions with them are correctly handled in relation to the DID Subject. (e.g. retain all variants in a database relationship so a login with any one of them maps back to the same UUID row for the DID Subject)

[timcappalli]

Two things dawned on me:

1. Canonical switching of IDs is not really what we are after here
2. There is a more general way to address the true need: expressing multiple deterministic variants of an ID

To that end, I believe a deterministicSameAs property (feel free to bikeshed the name) would do a much better job enabling the features/functions we need:

The deterministicSameAs property is an array of one or more DID URI strings that are verified by the DID Method to be deterministically provable variants of the DID in the id property which MAY be included in the DID Document. The resolving party MUST treat the DID in the id property and all DIDs present in the deterministicSameAs array as references to the same logical ID, thus the resolving party MUST retain the DID URIs from the id and deterministicSameAs properties to ensure any subsequent interactions with them are correctly handled in relation to the DID Subject. (e.g. retain all variants in a database relationship so a login with any one of them maps back to the same UUID row for the DID Subject)

@csuwildcat makes sense to me!

[troyronda]

Canonical switching of IDs is not really what we are after here

@csuwildcat A DID method can still have a preference for a certain form of the DID.

A Sidetree based DID method VDR (client) implementation needs to decide to switch to short form after observing it has been published.

Similarly in our case (mentioned above) where we switch from a domain in the network segment to a genesis hash. The DID method has a preference for the genesis hash form of the DID.

The VDR/app needs to be aware that some DID methods have this preference behavior, so that it uses the preferred DID form once available.

It would be best to be able to signal the preferred/canonical form generically. The current draft has a signal during resolution where the subject ID can be the canonical form - which is where this thread started - and this capability is still valuable.

[csuwildcat]

@troyronda I agree that a separate canonical or redirection property is certainly a good idea, and would support an additional PR to express that distinct need.

[OR13]

Two things dawned on me:

1. Canonical switching of IDs is not really what we are after here
2. There is a more general way to address the true need: expressing multiple deterministic variants of an ID

To that end, I believe a deterministicSameAs property (feel free to bikeshed the name) would do a much better job enabling the features/functions we need:

The deterministicSameAs property is an array of one or more DID URI strings that are verified by the DID Method to be deterministically provable variants of the DID in the id property which MAY be included in the DID Document. The resolving party MUST treat the DID in the id property and all DIDs present in the deterministicSameAs array as references to the same logical ID, thus the resolving party MUST retain the DID URIs from the id and deterministicSameAs properties to ensure any subsequent interactions with them are correctly handled in relation to the DID Subject. (e.g. retain all variants in a database relationship so a login with any one of them maps back to the same UUID row for the DID Subject)

I assume this is now a request for 2 new did document properties?

• deterministicSameAs
• canonicalId

Both seem like they are more accurately described as DID Document Meta Data, rather than DID Document Properties.

It seems like hidden inside these proposals is the desire to require an RP to be able to switch on did document properties instead of did resolution meta data.

I think the statements about the RP are untestable.

I wrote some tests associated with these "long and short form" ids here: https://github.com/transmute-industries/vc.js/blob/master/packages/vc.js/src/vc-ld/__tests__/long-form-did.sanity.test.ts

TL;DR; is that when you have 2 identifiers and the DID Method wants to say they are the same... thats a use case for OWL sameAs.... and any RP that is aware of both will have to support both forever (extra burden on RPs).

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

Before continuing on this thread, please review:

• https://github.com/w3c-ccg/security-vocab/issues/44
• https://github.com/w3c-ccg/security-vocab/pull/45

@msporny strongly objected to the use of OWL, but I wonder if we limited the use of sameAs to "only a did method can set this property" would the objection continue? IIRC you mostly objected to the idea that a controller could set sameAs.

alsoKnownAs is also not an option, since it's set by the controller.

IMO the correct solution to this is:

1. define OWL sameAs, and limit it to only being set by a DID Method (never a did controller, for security reasons)
2. add recommendations around how RPs should treat sameAs / alsoKnownAs

And since the question will come up.... yes, the content present in both did documents MUST be identical for the property to apply... only the controller and id fields would change between values of sameAs, a DID Method can require this to be true.

[csuwildcat]

@OR13 the owl:sameAs is about two individuals sharing the same identity, not two identifiers being deterministically synonymous variants of the exact same logical ID:

"The built-in OWL property owl:sameAs links an individual to an individual. Such an owl:sameAs statement indicates that two URI references actually refer to the same thing: the individuals have the same identity".

Regardless of who sets the property, owl sameAs is simply the wrong semantic, and not what this is about.

[msporny]

I wonder if we limited the use of sameAs to "only a did method can set this property" would the objection continue? IIRC you mostly objected to the idea that a controller could set sameAs.

Yes, if owl:sameAs is limited to the DID Method setting it and it's usage is within the same ledger (e.g., did:ion:1 sameAs did:ion:2), that's a safe usage of owl:sameAs because that is exactly what is being asserted -- pure semantic equivalence.

I'll also note that this is a super annoying burden on RPs. The DID Method is exposing its implementation beyond the DID Document and causing the rest of the ecosystem to get more complicated as a result. I expect active lobbying against the complexity of such a DID Method. :(

[csuwildcat]

Any lobbying against this will come from folks who don't have to deal with relativistic anchoring in decentralized systems, which is actually a fantastic litmus test that likely indicates they are not building truly decentralized DID Methods. There are many reasons IDs in a system can have exact deterministic synonyms/aliases, and the inability for a controller to present them securely to ensure exact equivalence recognition across them would be a big problem.

[csuwildcat]

@msporny if we can point to owl:sameAs and provide the same clarifying language for requirements/handling as I have in the associated PR, I could live with that.

[OR13]

@msporny completely agree with you, and to get the lobbying started... nobody should be using the "LongForm" specifically because of this issue, however... I can't stop it, Microsoft is committed to forcing this burden on RPs, and I would like to at least have the equivalence formally documented.... if it's not documented, they will just do it anyway.

@csuwildcat Let me rephrase your proposal in language I would not object to:

1. define sameAs: string[] as a property of the did subject (in the did document)
2. sameAs MUST only be set by a DID Method (never a did controller / possibly untestable statement).
3. the did document returned by resolving sameAs MUST be identical except for controller and id values.

Note that I didn't say anything about "determinism and identifiers"... its not needed and overly coupled to sidetree's use case.

will this work for you @csuwildcat ?

[msporny]

This issue will be resolved once PR #431 is merged.

[msporny]

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