Explain motivations for CID

[brentzundel]

From comment source

As stated in the Revision History section, this specification was created "to use non-decentralized identifiers and systems". Those are already inclusively supported in DIDs, which chose a federated approach. If the editors wish to propose any other reason for this specification's existence, they should add a Motivation section in the Introduction explaining the reason.

[iherman]

The issue was discussed in a meeting on 2025-04-23

• no resolutions were taken

View the transcript

1.4. CID.

Michael Jones: I registered the media type.

Brent Zundel: We had a number of comments on this one.

"Too similar to the code did specification. I wish it were presented as a clear extension of the did core specification that was clear about what’s different".

Brent Zundel: comment source, answered by team contact.

Brent Zundel: Ivan has responded to this comment, it is a superset of DIDs.

"§1 Introduction should note why the CID specification is necessary as those with less experience might see it as a recommendation over Decentralized Identifiers (DIDs) v1.0 rather than providing an abstraction to further make the case of DIDs.".

Brent Zundel: comment source.

Brent Zundel: They've asked for justification of the technology.

See github issue cid#154.

Brent Zundel: We thank the commenter, we will try to address the concern in a future version of the specification.

Ivan Herman: Can we make a minor change to address this issue?

Manu Sporny: We should take our time to pick wording that's not controversial.

Brent Zundel: Agree with that approach.

"As stated in the Revision History section, this specification was created "to use non-decentralized identifiers and systems". Those are already inclusively supported in DIDs, which chose a federated approach. If the editors wish to propose any other reason for this specification's existence, they should add a Motivation section in the Introduction explaining the reason.".

Brent Zundel: comment source.

See github issue cid#155.

Brent Zundel: The commenter here has pointed out that DIDs support this already -- we should add a motivation section. This is similar to the previous comment, but again, we should take our time to address this in the next version of the spec to make sure we pick language carefully.
… Any other comments on this one?

[iherman]

This was discussed during the vcwg meeting on 25 April 2025.

View the transcript

CID

<brent> w3c/cid#154, w3c/cid#155

selfissued: I registered the media type.

brent: We had a number of comments on this one.

<brent> "Too similar to the code did specification. I wish it were presented as a clear extension of the did core specification that was clear about what’s different"

<brent> comment source, answered by team contact

brent: Ivan has responded to this comment, it is a superset of DIDs.

<brent> "§1 Introduction should note why the CID specification is necessary as those with less experience might see it as a recommendation over Decentralized Identifiers (DIDs) v1.0 rather than providing an abstraction to further make the case of DIDs."

<brent> comment source

brent: They've asked for justification of the technology.

brent: We thank the commenter, we will try to address the concern in a future version of the specification.

ivan: Can we make a minor change to address this issue?

manu: We should take our time to pick wording that's not controversial.

brent: Agree with that approach.

<brent> "As stated in the Revision History section, this specification was created "to use non-decentralized identifiers and systems". Those are already inclusively supported in DIDs, which chose a federated approach. If the editors wish to propose any other reason for this specification's existence, they should add a Motivation section in the Introduction explaining the reason."

<brent> comment source

brent: The commenter here has pointed out that DIDs support this already -- we should add a motivation section. This is similar to the previous comment, but again, we should take our time to address this in the next version of the spec to make sure we pick language carefully.

brent: Any other comments on this one?

---