search

w3c / did-core

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

Fix editorial/normative issues in DID Parameters. #627

Closed msporny closed 3 years ago

msporny commented 3 years ago

Mostly editorial clean ups. Two normative REQUIRED statements around service and relativeRef were downgraded to OPTIONAL because keeping them at REQUIRED would make the did:key DID method invalid -- did:key has no support for service endpoints or relativeRef.

Preview | Diff

peacekeeper commented 3 years ago

Strictly speaking, I don't think having those parameters REQUIRED makes did:key invalid. You can construct a valid DID URL such as:

did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6?service=agent&relativeRef=/credentials

and a DID URL dereferencer would totatlly be able to process it. The functionality associated with this parameter is independent of the DID method. In the case of did:key, it would just always happen to return a notFound error, because there's no service in the DID document, but that doesn't mean the DID method is invalid.

Anyway, I would still be fine with changing REQUIRED to OPTIONAL, no objection...

But could you maybe add the example back in? Or is there a reason for deleting it?

msporny commented 3 years ago

Strictly speaking, I don't think having those parameters REQUIRED makes did:key invalid. You can construct a valid DID URL such as:

did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6?service=agent&relativeRef=/credentials

and a DID URL dereferencer would totatlly be able to process it.

That line of reasoning would mean that we could make every DID Parameter REQUIRED. It also depends on the meaning of "REQUIRED"... which typically means that you must include specific code for the feature. To say that did:key MUST support service by stating that it doesn't support it, is strange. There is no such thing as a service property in a did:key document, or relative references for that matter. Weakening the requirement to OPTIONAL doesn't create any issues that I can think of... and therefore, we can weaken it and address all concerns.

The functionality associated with this parameter is independent of the DID method. In the case of did:key, it would just always happen to return a notFound error, because there's no service in the DID document, but that doesn't mean the DID method is invalid.

It's sounding like the requirement is on DID URL dereferencers, not the DID syntax (which is what this section is about). A future PR should probably make that distinction.

Anyway, I would still be fine with changing REQUIRED to OPTIONAL, no objection...

Acknowledged.

But could you maybe add the example back in? Or is there a reason for deleting it?

The versionTime example was moved to the top. I deleted the service=agent example because it's not clear what that example is attempting to express.

msporny commented 3 years ago

Editorial, multiple reviews, changes requested and made, no objections, merging.