Update references to "UUIDs" in index.bs #4
Conversation
Tweeddalex
requested review from
ankurdotb,
peacekeeper,
talltree,
OR13 and
jandrieu
as code owners
|
I think it would be good to split this PR into two separate PRs. +1 to changing UUIDs to more generic "unique identifier", depending on what a certain DID method may want to use. Regarding ambiguity around verification relationships, that's a bit more tricky. First, I think the text doesn't say whether a verification relationship is required at all (and which one), or if it's enough to use any verification method in the DID document. And second, the logic described now in this PR would differ from e.g. how some implementations verify signatures on a VC, and from an algorithm described in the "Controller Documents" spec: https://w3c.github.io/controller-document/#retrieve-verification-method So I'd propose to maybe make this PR only about the UUIDs, and create a separate PR about the control topic? |
| @@ -82,14 +82,14 @@ Using traditional web endpoints to store digital resources that are critical for | |||
| DID-Linked Resources construction {#contruction} | |||
| --------------------- | |||
|
|
|||
| "Resources" SHOULD be identifiable using a Decentralized Identifier (DID) and a Universally Unique Identifier (UUID) that acts as a permanently-accessible identifier to fetch the Resource from a Verifiable Data Registry or other storage endpoint. We refer to this UUID as the "Resource ID". | |||
| "Resources" SHOULD be identifiable using a Decentralized Identifier (DID) and a permanently-accessible unique identifier to fetch the Resource from a Verifiable Data Registry or other storage endpoint. We refer to this identifier as the "Resource ID". | |||
There was a problem hiding this comment.
Should we start using RIDs ("Resource Identifiers") like DIDs?
There was a problem hiding this comment.
@peacekeeper @ankurdotb have removed the "control" section and will keep this just to the changes in identifier
index.bs
Outdated
| Control of Linked Resources {#control} | ||
| ===================== | ||
|
|
||
| A DID-Linked Resource can only be created if the transaction is signed by the same Verification Method keys that are defined in the parent DID Document. This ensures that the DID-Linked Resource shares the same cryptographic trust properties as the Parent DID, in terms of its creation and subsequent updates. It also ensures that new versions of a Resource can only be made by the Controller of the parent DID. | ||
|
|
||
| <div class="note"> <b>Note:</b> There is ambiguity in the DID Core specification around how Verification Method relationships can be used for different purposes. For example, some methods may use keys embedded within fields like 'capabilityDelegation' or 'keyAgreement' for specific purposes. To avoid ambiguity in implementation, this specification has chosen to require the keys to create DID-Linked Resources to be described in the Verification Method section of the parent DID Document. |
There was a problem hiding this comment.
I would say this should be the key(s) mentioned under authentication, which is the normative section in DID Core specification for the DID subject to authenticate. This is a clearer way of stating this, rather than stating the keys in the "Verification Methods" are used. A key might be mentioned under Verification Methods, but NOT referenced under authentication. A good example of this is how Dock defines BBS+ related keys in Verification Methods, but does not reference them in the authentication section. Finally, you can have inline definitions of keys in authentication.
There was a problem hiding this comment.
I agree.. My comment was also essentially that both embedded and referenced keys should be supported, to be more aligned with VCs, Controller Documents, and other things.
There was a problem hiding this comment.
I like this approach as well
Co-authored-by: Ted Thibodeau Jr <[email protected]>
SHA: 9e3ae61 Reason: push, by @Tweeddalex Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
No description provided.