Clarify id prop language to allow equivalent DID values #376

csuwildcat · 2020-08-20T00:35:13Z

OR13

based on conversation we had this seems pretty critical :)

I think most readers would assume as you did, that the current language is MUST, not a SHOULD.... I think this correction is helpful.

kdenhartog · 2020-08-21T01:38:06Z

index.html

@@ -1330,8 +1330,10 @@ <h2>DID Subject</h2>
 such as when a <a>DID resolver</a> is performing <a>DID resolution</a>.
 However, the fully resolved <a>DID document</a> always contains a valid
 <code><a>id</a></code> property. The value of <code><a>id</a></code> in the
-resolved <a>DID document</a> is expected to match the <a>DID</a> that was
-resolved.
+resolved <a>DID document</a> SHOULD match the <a>DID</a> that was


Wait this isn't a MUST? Seems odd to me that I'd map did:example:123 => { "id": "did:example:456", ... }

Can we provide some further detail on why this is best left as a should?

csuwildcat · 2020-08-21T04:29:38Z

There was no normative, explicit directive at all before this, so I put in SHOULD simply because there was no feedback yet. Personally, I couldn't think of anything else it would/should ever be either, so I'm happy to go with MUST.

csuwildcat · 2020-08-21T04:30:31Z

@kdenhartog to be clear: if it was a MUST, it would be that it MUST be either the same as the resolved DID or the equivalent canonical DID the DID Method determines as part of its resolution logic.

csuwildcat · 2020-08-21T04:45:08Z

Sorry, GitHub's UI freaked out and bizarrely closed the issue, so pay no attention to the Closed entry 😜

csuwildcat · 2020-08-21T18:38:10Z

@kdenhartog @OR13 changed the directive from SHOULD to MUST, as I agree with you that this proposed language is a sensible one-way requirement.

index.html

kdenhartog · 2020-08-23T22:35:59Z

index.html

-resolved <a>DID document</a> is expected to match the <a>DID</a> that was
-resolved.
+resolved <a>DID document</a> MUST match the <a>DID</a> that was
+resolved, or be populated by the <a>DID method</a> with another <a>DID</a> it 


I'm good with this. The "or..." statement seems like it could cause some tricky issues with how de-referencing would work on identifying the did document, such as sub-objects (verificationMethod block, service block, etc) being identified with a different base did than the top level id. However, since the point of this statement is to point out that the method authors must state how it's canonically mapped, I think it should work out fine as long as the method is written properly.

Co-authored-by: Dave Longley <[email protected]>

csuwildcat · 2020-08-24T21:52:26Z

@msporny I added in @dlongley's change, so I think we're good, right?

brentzundel · 2020-08-24T22:48:45Z

index.html

+resolved <a>DID document</a> MUST match the <a>DID</a> that was
+resolved, or be populated according to the <a>DID method</a> with another
+<a>DID</a> it specifies is the equivalent canonical <a>DID</a> for the <a>DID</a> 
+that was resolved.


Suggested change

resolved <a>DID document</a> MUST match the <a>DID</a> that was

resolved, or be populated according to the <a>DID method</a> with another

<a>DID</a> it specifies is the equivalent canonical <a>DID</a> for the <a>DID</a>

that was resolved.

resolved <a>DID document</a> MUST match the <a>DID</a> that was

resolved, or be populated with the equivalent, canonical <a>DID</>

as specified by the relevant <a>DID method</a>.

I understood what you were saying and like the change, but the wording felt kind of clumsy, so this is my attempt to wordsmith.
Just a suggestion.

Two things here I want to note:

Where it says THE equivalent canonical DID, was intentional to make sure that it was a singular relationship, where as a change to an equivalent canonical DID seems to suggest that it is selecting from many. I think it would be best to leave this the.

While I am fine with the general change of the wording to as specified by the related DID method, do you think we should use a different word that related here? I ask because this is about relationships between things, and maybe we should be more explicit that its not just the related method, its the Method of the DID being resolved.

good points, suggestion has been updated.

brentzundel · 2020-08-25T18:39:21Z

.vscode/settings.json

@@ -0,0 +1,3 @@
+{


looks like you might have inadvertently added some personal IDE settings to the PR.

I wish we all used vs code and agreed to committed settings... like auto format or not.... every w3c repo i work in, i have a bunch of settings disabling my default behavior, like format on save... but yea, probably a mistake to commit this file.

Didn't realize I had, I can delete.

peacekeeper · 2020-08-25T21:49:28Z

I cannot say exactly why, but I feel slightly uncomfortable with allowing the id property to contain anything other than the DID that was resolved.

Another solution to this use case (besides the idea of a canonical link relation discussed in #368) could be to return a null DID document, plus resolution metadata which contains the canonical DID that should be resolved instead. This would be comparable to HTTP's redirect status codes.

E.g. if you resolve did:example:123, the result of the resolve() function would be:

did-resolution-metadata = «["redirect" → "did:example:456"]»
did-document = null
did-document-metadata = null

A resolver could be configured to automatically follow such redirects, to make this transparent for the client.

csuwildcat · 2020-08-25T23:28:51Z

I really think making some sort of canonical redirect from one DID to another based on having to generically follow data/directives in the resolution metadata to another DID/DID Document, then making the same inference in the end you would have this way, is going to require a ton more spec text across multiple specs (some outside of the DID Core spec) and will be prone to devs footgunning themselves with the complexity and ergonomic issues. The unidirectional nature of the canonical value language is the most objective/empirical of all the equivalence expressions we have discussed, so I really hope we can at least get this in. If not, I would hope the fallback is a specific property like canonical being added, because going through redirect hoops seems like a lot of complexity for very little benefit.

msporny · 2020-08-30T16:36:22Z

I'll note that the last SHOULD in this statement is not testable and may be changed to "is expected to be used during future resolution requests."

Normative, multiple reviews, changes requested and made, no objections, merging.

Modify id prop to clarify equivalent DID allowance

cbde13f

OR13 approved these changes Aug 20, 2020

View reviewed changes

kdenhartog reviewed Aug 21, 2020

View reviewed changes

csuwildcat closed this Aug 21, 2020

csuwildcat reopened this Aug 21, 2020

Update normative directive from SHOULD to MUST

39c4d39

dlongley reviewed Aug 21, 2020

View reviewed changes

index.html Outdated Show resolved Hide resolved

kdenhartog approved these changes Aug 23, 2020

View reviewed changes

Update index.html

be5f177

Co-authored-by: Dave Longley <[email protected]>

brentzundel reviewed Aug 24, 2020

View reviewed changes

Update to add in requested changes

0b0e82d

brentzundel reviewed Aug 25, 2020

View reviewed changes

Daniel Buchner added 2 commits August 26, 2020 07:11

removing errant vscode settings file

e03e448

update to more closely match suggestions

2559e6a

dlongley approved these changes Aug 26, 2020

View reviewed changes

brentzundel approved these changes Aug 26, 2020

View reviewed changes

msporny approved these changes Aug 30, 2020

View reviewed changes

msporny merged commit 24d042d into w3c:master Aug 30, 2020

tplooker mentioned this pull request Sep 29, 2020

Current language around equivalent canonical DIDs increases signature verification complexity #421

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify id prop language to allow equivalent DID values #376

Clarify id prop language to allow equivalent DID values #376

csuwildcat commented Aug 20, 2020 •

edited by pr-preview bot

Loading

OR13 left a comment •

edited

Loading

kdenhartog Aug 21, 2020

csuwildcat commented Aug 21, 2020

csuwildcat commented Aug 21, 2020 •

edited

Loading

csuwildcat commented Aug 21, 2020

csuwildcat commented Aug 21, 2020

kdenhartog Aug 23, 2020

csuwildcat commented Aug 24, 2020

brentzundel Aug 24, 2020 •

edited

Loading

brentzundel Aug 24, 2020

csuwildcat Aug 24, 2020

brentzundel Aug 25, 2020

brentzundel Aug 25, 2020

OR13 Aug 25, 2020 •

edited

Loading

csuwildcat Aug 25, 2020

peacekeeper commented Aug 25, 2020

csuwildcat commented Aug 25, 2020

msporny commented Aug 30, 2020 •

edited

Loading

Clarify id prop language to allow equivalent DID values #376

Clarify id prop language to allow equivalent DID values #376

Conversation

csuwildcat commented Aug 20, 2020 • edited by pr-preview bot Loading

OR13 left a comment • edited Loading

Choose a reason for hiding this comment

kdenhartog Aug 21, 2020

Choose a reason for hiding this comment

csuwildcat commented Aug 21, 2020

csuwildcat commented Aug 21, 2020 • edited Loading

csuwildcat commented Aug 21, 2020

csuwildcat commented Aug 21, 2020

kdenhartog Aug 23, 2020

Choose a reason for hiding this comment

csuwildcat commented Aug 24, 2020

brentzundel Aug 24, 2020 • edited Loading

Choose a reason for hiding this comment

brentzundel Aug 24, 2020

Choose a reason for hiding this comment

csuwildcat Aug 24, 2020

Choose a reason for hiding this comment

brentzundel Aug 25, 2020

Choose a reason for hiding this comment

brentzundel Aug 25, 2020

Choose a reason for hiding this comment

OR13 Aug 25, 2020 • edited Loading

Choose a reason for hiding this comment

csuwildcat Aug 25, 2020

Choose a reason for hiding this comment

peacekeeper commented Aug 25, 2020

csuwildcat commented Aug 25, 2020

msporny commented Aug 30, 2020 • edited Loading

csuwildcat commented Aug 20, 2020 •

edited by pr-preview bot

Loading

OR13 left a comment •

edited

Loading

csuwildcat commented Aug 21, 2020 •

edited

Loading

brentzundel Aug 24, 2020 •

edited

Loading

OR13 Aug 25, 2020 •

edited

Loading

msporny commented Aug 30, 2020 •

edited

Loading