Conform to did:peer:2 spec #3
Conversation
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Since we aren't getting the capability delegation/invocation from the DID, we shouldn't be including them in the DIDDoc since they weren't specified to begin with. Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
|
Relevant PR to Peer DID Method spec: decentralized-identity/peer-did-method-spec#62 |
|
Just a slight nudge in case this issue slipped through your notifications, @brianorwhatever |
|
oh thanks @frostyfrog totally missed this in my queue. thanks for the nudge will take a look today! |
There was a problem hiding this comment.
@frostyfrog this looks good for the most part the main thing I'd like to see changed is the absolute vs relative id properties. Really we should be using absolute id values for the service blocks as well as this is currently not valid JSON-LD but I think it's ok to leave them as relative as that is how that they were originally.
| publicKeyMultibase: k.slice(1) | ||
| }) | ||
| break; | ||
| case Numalgo2Prefixes.KeyAgreement: | ||
| encKeys.push({ | ||
| id: `${did}#${k.slice(2)}`, | ||
| id: `#key-${keyIndex++}`, |
There was a problem hiding this comment.
I prefer absolute URIs over relative. I know the spec uses relative and these get quite ugly but I don't think it will matter at an interoperability level unless I'm missing something
There was a problem hiding this comment.
I believe you're correct; whether the URLs are "expanded" or left as relative should not significantly impact interop as either should be considered acceptable. Using absolute URIs here I think is fair. @frostyfrog
There was a problem hiding this comment.
Alternatively I'd be ok with using relative and putting an "@base": "did:peer:2z123najb..." in the @context which will effectively do the same thing
There was a problem hiding this comment.
I like the idea of using @base as it allows the document to be a bit cleaner when a Human is reading it. I have added it to the context property according to the pattern demonstrated in example 150 in the JSON-LD docs.
| controller: did, | ||
| type: 'X25519KeyAgreementKey2020', | ||
| type: 'Multikey', |
There was a problem hiding this comment.
Cool to use new Data Integrity suites. I need to update my other libraries but will pin versions if I can't get to updating them as this is the right path forward
| verificationMethod: ver, | ||
| } | ||
| if (didPeerNumalgo < 2) { |
There was a problem hiding this comment.
did:peer:2 doesn't have capabilityDelegation or capabilityInvocation?
There was a problem hiding this comment.
did:peer:2 does support expressing capabilityDelegation and capabilityInvocation but, unfortunately, only as an explicitly marked value; for instance: .Dz6Mkj3PUd1WjvaDhNZhhhXQdz5UnZXmS7ehtx8bsPpD47kKc will cause the key with multikey material z6Mkj3PUd1WjvaDhNZhhhXQdz5UnZXmS7ehtx8bsPpD47kKc to be added to the verification method list and a reference added to capabilityDelegation but not into any other verification relationship.
It is because of limitations like these that we're moving to did:peer:4 which can express any DID Document without limitations.
There was a problem hiding this comment.
I'm not sure what needs to be done here as Delegation and Invocation are foreign diddoc concepts to me. All of my recent work has revolved around .E and .V. I've only seen references to .I and .D and I've never seen them used in practice.
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
Since @base only affects relative IRIs, we can just have it exist always, generally. See this resource for more information on @base and how it works: https://www.w3.org/TR/json-ld11/#syntax-tokens-and-keywords Signed-off-by: Colton Wolkins (Laptop) <[email protected]>
|
@frostyfrog I have published |
|
Unfortunately, I don't have any immediate way to test. I could set something up, though it would take some time to do so. As described over at decentralized-identity/peer-did-method-spec#64, there were 4 other apps/libs that need updating before https://dev.uniresolver.io/ would start working (which is where I first discovered the issue). For all I know, they might just grab the change or they might each need to be rebuilt and updated. I'll take a look into what needs to happen in order to test that things are working when I have a spare moment. |
I ran into an issue with the universal resolver in which it was unable to resolve
did:peer:2dids which contained multiple service blocks. I tracked the issue down to the regex check in this library and when I brought it up with @dbluhm, it was recommended that I make other fixes while I was already fixing the service issue. With recent clarifications and fixes to the did:peer numalgo 2 spec, the appropriate clarifications have been applied to this spec.