search

w3c-ccg / did-spec

Please see README.md for latest version being developed by W3C DID WG.
https://w3c.github.io/did-core/
Other
124 stars 45 forks source link

Refactor ABNF rules for DIDs and DID References. #168

Closed dmitrizagidulin closed 5 years ago

dmitrizagidulin commented 5 years ago

This PR integrates and reflects the current consensus on the DID ABNF rules, as well as DID Reference and Service Endpoint ABNF rules.

Specifically:

Replaces PR #106, addresses #85.

Preview | Diff

dmitrizagidulin commented 5 years ago

ABNF rules refactored. What remains (this should probably go in a separate PR? I'm not sure):

mwherman2000 commented 5 years ago

How soon can this PR be accepted?

davidlehn commented 5 years ago

@dmitrizagidulin If the preview link is correct, there's a <section> tag issue somewhere. Everything is under section 4, vs the current version where that is not the case.

davidlehn commented 5 years ago

@dmitrizagidulin Does terms.html needs some updating too to match these changes? For instance, the metions and links about "DID Path" . (And while fixing that, maybe reword so the hard coded easy breakable "section x.y" text in that file isn't used)

davidlehn commented 5 years ago

There are more places where the def <a>term</a> style could be used. Unsure how far that sort of linking needs to go.

dhh1128 commented 5 years ago

I do not understand why we feel the need to use a different delimiter to distinguish service fragments from other types of fragments. Why can't we just use / for all fragments of any type, and require that their ID properties be unique within the DID Document?

mwherman2000 commented 5 years ago

@dhh1128 I agree. At the did-url grammar level, we should focus on a minimum set of allowable syntax constructs - in support of the desired capabilities we want did-urls to have ...not try to encode all sorts of specific capabilities and functions into the grammar expressed using the ABNF notation.

Examples:

  1. IMO a bad use of syntax: https://github.com/WebOfTrustInfo/rwot8-barcelona/pull/164#issuecomment-470869225
  2. IMO a better use of syntax: https://github.com/w3c-ccg/did-resolution/issues/32#issuecomment-471179669

The latter, at a syntax (grammar) level, supports many levels of functional/capability innovation without having to change the grammar. It creates an "algebra" for working with a did and collections of dids, etc.

peacekeeper commented 5 years ago

@dmitrizagidulin do you think everything in this PR has been addressed by https://github.com/w3c-ccg/did-spec/pull/189 (in fact, that one even cherry-picked a few commits from here)? Or would you say this PR here still has content that needs to be merged?

kdenhartog commented 5 years ago

I wanted to highlight the example of what I brought up on the DID call today about key-type matrix param being used as a method to specify a specific key-type within a grouping of key-types. For example, let's say in my DID-Doc I specify a grouping of RSAVerificationKey2016 RSAVerificationKey2017 and RSAVerificationKey2018 and call this grouping RSAVerificationSuite which is what the key-type would be listed in my DID Doc.

E.g. my DID Doc would be:

{
  "@context": ["https://w3id.org/did/v1", "https://w3id.org/security/v1"],
  "id": "did:example:123456789abcdefghi",
  ...
  "publicKey": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationSuite",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  ...
}

Then when referencing to the public key for verification, I could use did:example:123456789abcdefghi;key-type=RSAVerification2018#keys-1

To suggest that the same key can be used with multiple key types.

If you were to use this for service-type it would be something like a grouping of services where a common set of services sit behind a single endpoint. So for example, I may run an Agent which supports DIDComm v1 and DIDCommv2 and I would specify the serialization of the object by using:

did:example:123456789abcdefghi;key-type=DIDComm-JSON#agent

or

did:example:123456789abcdefghi;key-type=DIDComm-CBOR#agent

This is just an early example of where I think it may be used. I'm not sure if this indirection is useful, necessary, or neither. With that said, I want to take the time to agree with @dmitrizagidulin point raised that matrix params are not a method of optimizing resolver implementations. They should be used to identify a specific resource when the DID Doc contains metadata that describes a set.

dmitrizagidulin commented 5 years ago

This PR is superceded by PR #189, so, it's ok to close this one.