search

w3c / did-core

W3C Decentralized Identifier Specification v1.0
https://www.w3.org/TR/did-core/
Other
395 stars 93 forks source link

Prepare Candidate Recommendation 2 specification. #757

Closed msporny closed 3 years ago

msporny commented 3 years ago

This PR implements the following request by the Chairs:

https://lists.w3.org/Archives/Public/public-did-wg/2021May/0023.html

I'm marking this as substantive, not because it contains any substantive changes to the specification... but because it re-starts the CR clock and because it might lead to substantive changes to the specification.

Preview | Diff

msporny commented 3 years ago

I wonder whether putting did+ld+json at risk should not be replaced by putting all media types at risk.

I'm very concerned about that path -- removing media types from the specification at this point in the process. Media type reporting is built into production, consumption, resolution, and dereferencing. It would be major surgery to remove them at this point.

Instead, we will most likely be forced to choose media type identifiers... so the only question now is "which ones will we choose?" :)

Clearly, we'll need to discuss this on the Tuesday call.

iherman commented 3 years ago

Clearly, we'll need to discuss this on the Tuesday call.

Yep!

TallTed commented 3 years ago

I saw another document recently (might have been an RFC, or a W3 Rec, or something else; I wish I'd made specific note of it!) that had an IANA Considerations section that basically said, "Until and unless IANA officially says otherwise, we recommend using this media type for outputs produced according to the other guidance herein." I wonder if we could get away with doing that for application/did+ld+json?

msporny commented 3 years ago

I wonder if we could get away with doing that for application/did+ld+json?

That is exactly the sort of approach I was thinking we should take, @TallTed.

msporny commented 3 years ago

Marking this as "do not merge" as we're going to create the CR2 right off of this branch, publish it, and then if everything goes well... merge (and strictly in that order to avoid polluting this branch with progress we're making in parallel on the main branch, which will result in restarting the review clock).

msporny commented 3 years ago

Potentially substantive (if at risk markers are acted upon), broadly discussed in WG telecons and on mailing list, multiple reviews, no objections, merging.