Closed decentralgabe closed 6 months ago
A few discussion topics that come to mind -- raising to discuss but not state a strong preference:
publicKeyMultibase
in our SDKs or drop it?contentType
property referenced here should never be present in DID Resolution Metadata unless the result is being returned by the resolveRepresentation
function. Since our SDKs today only support the resolve
function, we can likely leave it out for now.Responding in place.
- Any particular reason we don't require the verification relationship entries be fully qualified DID URIs? I'm trying to think of a case where we'd want to support relative DID URIs and haven't come up with one but I'm probably overlooking a scenario.
Some DID methods, like did key don't do this. I know we already have impls for these so I didn't want to break them.
- Should we require support for
publicKeyMultibase
in our SDKs or drop it?
Similarly, this is a requirement of our existing did:key support. We may encounter keys encoded like this with did:web but that's less of a concert to me.
- It's worth noting that
contentType
property referenced here should never be present in DID Resolution Metadata unless the result is being returned by theresolveRepresentation
function. Since our SDKs today only support theresolve
function, we can likely leave it out for now.
Good call out. I will remove the property entirely.
- Any particular reason we don't require the verification relationship entries be fully qualified DID URIs? I'm trying to think of a case where we'd want to support relative DID URIs and haven't come up with one but I'm probably overlooking a scenario.
Some DID methods, like did key don't do this. I know we already have impls for these so I didn't want to break them.
It appears that the DID Key method requires that the id
property be used in verification relationships so spec compliant implementations should be using fully qualified DID URIs:
https://w3c-ccg.github.io/did-method-key/#document-creation-algorithm
Are there well used DID Key libs that use relative DID URIs that you're aware of?
@frankhinek my mistake! you are correct. I will update the guidance to require fully qualified URIs.
Going to merge tomorrow pending objections/final review. cc: @mistermoe @frankhinek @phoebe-lew @KendallWeihe @nitro-neal @jiyoontbd @kirahsapong
merging but open to putting additional feedback in an upcoming PR
PR is ready for review. Two follow ups:
123
126