Add dependency on CID spec. #877

msporny · 2025-01-03T21:37:41Z

This PR is an attempt to address issue #854 by normatively referencing the Controlled Identifiers specification.

WARNING: This is a BIG PR -- as was requested by the WG. Please keep discussions and change requests limited to editorial changes and suggestions and raise a separate issue, if needed, to track larger structural change requests.

Preview | Diff

TallTed

Small editorial tweaks

TallTed · 2025-01-06T00:02:34Z

index.html

+<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL
+syntax which are compatible with Section <a href="#did-syntax"></a>.


I don't understand what the compatibility is, in order to rephrase to make the sentence say so. Is it each of the strings or the URL syntax that is compatible with Section <a href="#did-syntax">?

Suggested change

<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL

syntax which are compatible with Section <a href="#did-syntax"></a>.

<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL

syntax which are compatible with Section <a href="#did-syntax"></a>.

This still reads oddly to me. It makes me think, controller property conforms to the URL syntax. URLs are compatible with the DID syntax.

Whereas the spec says:

The controller property is OPTIONAL. If present, the value MUST be a string or a set of strings that conform to the rules in 3.1 DID Syntax.

So I would use language similar to the id field.

... "that conforms to rules defined in Section ."

This is my best guess at what these lines are trying to say —

Suggested change

<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL

syntax which are compatible with Section <a href="#did-syntax"></a>.

<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL

syntax defined in Section <a href="#did-syntax"></a>.

TallTed · 2025-01-06T00:03:43Z

index.html

+<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL
+syntax which are compatible with Section <a href="#did-syntax"></a>.


As with lines 1268–1269, I don't understand what the compatibility is, in order to rephrase to make the sentence say so. Is it each of the strings or the URL syntax that is compatible with Section <a href="#did-syntax">? Here's my best guess at what these lines are trying to say —

Suggested change

<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL

syntax which are compatible with Section <a href="#did-syntax"></a>.

<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL

syntax defined in Section <a href="#did-syntax"></a>.

index.html

w3cbot · 2025-01-09T17:01:15Z

This was discussed during the #did meeting on 09 January 2025.

View the transcript

w3c/did-core#877

wip: Manu has done a lot of work to align this with other spec.

manu: The group requested that we do this as a PR. Normally I try to do this as an editorial change, but it's a massive change.
… What this is trying to do is that over the last year decisions have been made, and there's a subset of people that wanted to see a controlled identifier specification but use the web platform. That's the CID spec.
… That was basically a copy/paste of the DID spec, but with the DID stuff taken out.
… So we are removing duplication from the DID spec.
… It defers to the CID spec, saying that if you want to do things like "also known as", go to the CID spec, with the modulo that DIDs are allowed as well.
… and makes DID a requirement for the document ID.
… The only other issue I ran into is that since the CID spec is not published yet and is in TR space, a subset of the terminology is not yet published.
… That will hopefully be fixed in the next month, which should fix it. The PR is ready for review.
… It's a massive PR to layer the specs correctly.

ivan: The CID spec is not published in the TR space under that name. It was published under the name of Controller Document, just to be clear.
… Manu, last time you sent an email saying that there's a PR there but don't review it yet. Is it now ready for review?

manu: I removed the draft state and it is now ready for review.

markus_sabadello: Can you comment what this means for the abstract data model and consumption and production of entries that are set for update?

manu: I tried to make those changes in this PR and it became complicated. Some of the sections are still useful, but I'm going to try to do those in a separate PR.
… This PR does not attempt to remove the abstract data model. There is still some misalignment between the CID and DID specs, so I expect to make those changes later.

iherman

This is a PR for a FPWD draft version, so the result will still undergo a multitude of reviews and changes; I did not look at all the details (it is way too complex to review it that way. I have spotted, however, two major and a minor issue; I think the major issues should be taken care of before merging.

The PR still uses the "Controlled Identifiers Document" title for the CID specification, but the name has been changed (again) for "Controlled Identifier 1.0" by the VC WG. That should be used overall.
In §5.1.1 Did Subject the new text does not make it clear that, in a DID document, the value of id MUST be a DID. It sounds obvious, but the previous version makes a stronger statement.

It may be that this requirement is between the lines in other places of the document; I think re-enforcing here would still make sense

The same comment applies to the DID controller section.
Minor knit in §9 Privacy Consideration: "specification before reading this section is it contains more general privacy considerations" should say "specification before reading this section as it contains more general privacy considerations" ("is" -> "as")

TallTed · 2025-01-13T20:40:33Z

The PR still uses the "Controlled Identifiers Document" title for the CID specification, but the name has been changed (again) for "Controlled Identifier 1.0" by the VC WG. That should be used overall.

I think the new title is Controlled Identifiers 1.0 (with the pural), like Decentralized Identifiers, no?

msporny · 2025-01-13T22:20:45Z

I think the new title is Controlled Identifiers 1.0 (with the pural), like Decentralized Identifiers, no?

Yes, correct.

index.html

wip-abramson · 2025-01-17T14:59:06Z

index.html

+          <td>no</td>
+          <td>
+A <a data-cite="INFRA#ordered-set">set</a> of <a
+data-cite="INFRA#string">strings</a>, each of which conforms to


Again, aren't we constraining the values to conform to the DID URL syntax? Not just any URL

The value of the id property for a verification method MUST be a string that conforms to the rules in Section 3.2 DID URL Syntax.

This applies to all verificationRelationships below aswell

wip-abramson · 2025-01-17T15:05:13Z

index.html

-threshold signature.
+A <a>DID document</a> can express <a>verification methods</a>, as defined
+<a data-cite="CID#verification-methods">Section 2.2: Verification Methods</a> of
+[[[CID]]]. Identifiers used in <a>verification methods</a> can be expressed


Suggested change

[[[CID]]]. Identifiers used in <a>verification methods</a> can be expressed

[[[CID]]]. Identifiers used in <a>verification methods</a> MUST be expressed

Unless I am misunderstanding this alignment with the CID spec, I believe this is a normative requirement of the DID spec

wip-abramson · 2025-01-17T15:07:12Z

index.html

+<a data-cite="CID#verification-relationships">Section 2.3: Verification
+Relationships</a> of the [[[CID]]] specification. Identifiers used in
+<a>verification relationships</a>
+can be expressed according to <a href="#did-syntax"></a> and


Suggested change

can be expressed according to <a href="#did-syntax"></a> and

MUST be expressed according to <a href="#did-syntax"></a> and

peacekeeper · 2025-01-23T13:23:11Z

In noticed that the table "Verification Method properties" does not contain all the properties from the CID spec. Specifically, "expires" and "revoked" are missing.

jandrieu · 2025-01-23T16:30:17Z

Regarding hashlinks to secure URL identifiers for verification methods... I don't believe that works with dynamic documents.

msporny · 2025-01-23T18:50:08Z

Regarding hashlinks to secure URL identifiers for verification methods... I don't believe that works with dynamic documents.

As long as the canonicalized content in the dynamic document matches, it should work. I guess it depends on what you mean by "dynamic". That said, I don't think we provide any guidance for hashlinks, but I'll try to make sure we don't do that since it's under-defined right now.

pchampin · 2025-01-24T14:02:33Z

This was discussed during the did meeting on 23 January 2025.

View the transcript

w3c/did-core#877

manu: Not a lot has changed -- the big PR that rationalizes DID Core to depend on the CID spec.
… A tricky one -- hard to get it easily aligned.

Wip: In some places there seems to be normative changes. Notably around "id"s. Changing to URL.
… "identifiers used in verification methods can be changed to URLs"

manu: There is the use case that a DID Method points to a URL. Only change was made to the top most id (root). For all other IDs, noted that DID syntax is allowed -- although CID allows URLs.
… For service endpoints -- most of them are URLs -- but that has always been allowed.
… This PR allows for verificationMethods to be URLs on the web. If we don't have that, we lose the ability to do that.

Wip: This is a change. Is it a concern for others?

smccown: Not a problem. Does come back to a concern with LinkedData, as you can't verify it. You can't sign it and verify it and so it could change. We have accepted that in the past but its on ongoing concern.

JoeAndrieu: There has not been a use for URLs verificationMethods. There is no definition of how the VM is secured when it is a URL, unlike for a DID.

<Zakim> JoeAndrieu, you wanted to say it is not EVERYTHING must be a DID

manu: Could make it that it has to be a DID. If we say it has to be a DID, and they use did:web, we have the same issue. Entirely dependent on the DID Method. There is no protection in the base version of DID Web.

<dmitriz> +1 joe

JoeAndrieu: The difference is that did:web is a published method and it is available for discussion, weaknesses etc. If you just put a URL, you have not of that. Maybe SHOULD be a DID, and talk about the issues.

<dmitriz> (re SHOULD, and mentioning the issues in the spec)

<Zakim> manu, you wanted to suggest I just keep it at MUST be a DID. and to suggest SHOULD :P

markus_sabadello: Missed the comment.

manu: Reviewing the spec...its in the table about IDs and notably that a VM is a DID or a map.

<Wip> https://github.com/w3c/did-core/pull/877/files#r1920318242

manu: trying to decide on SHOULD or MUST. Since did:web could be used, then URL is the same. Maybe put it back to MUST, and then a separate discussion on backing off that.

PDL-ASU: Specs often talk about the securing and the issues. If the URL was a hashlink doesn't that give the security.

manu: Will open an issue to deal with this point separately. Re: PDL-ASU point -- there is not a way to make the hashlink of a fragment (as this is likely to be). So hard to handle via an HL. Could be ways to do that, but hard to do.

<PDL-ASU> Agreed that's the point Joe was raising. Sounds like we should write that down. :-)

Co-authored-by: Will Abramson <[email protected]> Co-authored-by: Ted Thibodeau Jr <[email protected]>

msporny · 2025-01-26T22:00:34Z

Substantive but editorial, multiple reviews, changes requested and made, no objections, merging.

msporny added the class 3 Other changes that do not add new features label Jan 3, 2025

msporny requested review from ChristopherA, davidlehn, jandrieu, peacekeeper, iherman, dmitrizagidulin, TallTed, decentralgabe, KDean-Dolphin and brentzundel January 3, 2025 21:37

msporny mentioned this pull request Jan 4, 2025

Normatively reference Controller Document #854

Closed

msporny marked this pull request as ready for review January 4, 2025 17:57

msporny requested review from mccown and danpape as code owners January 4, 2025 17:57

TallTed suggested changes Jan 6, 2025

View reviewed changes

iherman mentioned this pull request Jan 13, 2025

CR Request for Controlled Identifiers 1.0 - cid-1.0 w3c/transitions#691

Closed

iherman approved these changes Jan 13, 2025

View reviewed changes

wip-abramson reviewed Jan 17, 2025

View reviewed changes

index.html Outdated Show resolved Hide resolved

wip-abramson reviewed Jan 17, 2025

View reviewed changes

Update Core Properties section to depend on CIDs.

f045216

msporny added 4 commits January 26, 2025 15:31

Modernize examples in specification.

64c794f

Remove duplicated Security Considerations from CID spec.

82afc53

Remove duplicated Privacy Considerations from CID spec.

819f466

Clean up internal references to point to CID specification.

6edb213

msporny force-pushed the msporny-cid-alignment branch from 664def6 to 6edb213 Compare January 26, 2025 20:33

msporny and others added 2 commits January 26, 2025 16:54

Ensure that DIDs are required for certain properties.

1c71e45

Fix grammar and flow throughout the specification.

038009f

Co-authored-by: Will Abramson <[email protected]> Co-authored-by: Ted Thibodeau Jr <[email protected]>

msporny merged commit 5043231 into main Jan 26, 2025
1 check passed

msporny deleted the msporny-cid-alignment branch January 26, 2025 22:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add dependency on CID spec. #877

Add dependency on CID spec. #877

msporny commented Jan 3, 2025 •

edited by pr-preview bot

Loading

TallTed left a comment

TallTed Jan 6, 2025

wip-abramson Jan 17, 2025 •

edited

Loading

TallTed Jan 24, 2025

TallTed Jan 6, 2025 •

edited

Loading

w3cbot commented Jan 9, 2025

w3c/did-core#877

iherman left a comment

TallTed commented Jan 13, 2025

msporny commented Jan 13, 2025

wip-abramson Jan 17, 2025

wip-abramson Jan 17, 2025

wip-abramson Jan 17, 2025

wip-abramson Jan 17, 2025

peacekeeper commented Jan 23, 2025

jandrieu commented Jan 23, 2025

msporny commented Jan 23, 2025

pchampin commented Jan 24, 2025

w3c/did-core#877

msporny commented Jan 26, 2025

		<a data-cite="INFRA#string">strings</a>, each of which conforms to the URL
		syntax which are compatible with Section <a href="#did-syntax"></a>.

	[[[CID]]]. Identifiers used in <a>verification methods</a> can be expressed
	[[[CID]]]. Identifiers used in <a>verification methods</a> MUST be expressed

	can be expressed according to <a href="#did-syntax"></a> and
	MUST be expressed according to <a href="#did-syntax"></a> and

Add dependency on CID spec. #877

Add dependency on CID spec. #877

Conversation

msporny commented Jan 3, 2025 • edited by pr-preview bot Loading

TallTed left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wip-abramson Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TallTed Jan 6, 2025 • edited Loading

Choose a reason for hiding this comment

w3cbot commented Jan 9, 2025

iherman left a comment

Choose a reason for hiding this comment

TallTed commented Jan 13, 2025

msporny commented Jan 13, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peacekeeper commented Jan 23, 2025

jandrieu commented Jan 23, 2025

msporny commented Jan 23, 2025

pchampin commented Jan 24, 2025

msporny commented Jan 26, 2025

msporny commented Jan 3, 2025 •

edited by pr-preview bot

Loading

wip-abramson Jan 17, 2025 •

edited

Loading

TallTed Jan 6, 2025 •

edited

Loading