Did-core: Inconsistant namspace for `method` and/or `method-specific-id`

Created on 6 Nov 2019  路  7Comments  路  Source: w3c/did-core

ABNF says:

did                = "did:" method-name ":" method-specific-id
method-name        = 1*method-char
method-char        = %x61-7A / DIGIT
method-specific-id = *idchar *( ":" *idchar )

and spec says:

Both DID method namespaces and method-specific parameter namespaces MAY include colons, so they may be partitioned hierarchically as defined by a DID method specification. Here is an example DID URL that illustrates both:

did:foo:baz:21tDAKCERh95uGgKbJNHYp;foo:baz:hex=b612

According to the ABNF method can not have namespace but method-specific-id can.

If I understand it correctly it is not consistent as is not clear if method or method-specific-id can be namespaces.
Am I missing something?

PR exists

Most helpful comment

@mitfik I don't think there is a contradiction. Yes we are saying that "DID method namespaces" MAY include colons. But this doesn't mean that the method name (the ABNF method) includes colons. In your example:

did:foo:baz:21tDAKCERh95uGgKbJNHYp;foo:baz:hex=b612

The DID method is foo. You could say that this DID method's namespace (= everything under did:foo) is further partitioned by colons, i.e. by baz:. But the baz: is already part of the method-specific-id, not part of the method.

Other real-life examples include did:v1:test:nym:UxYjr6F3hqwiF3yffplpcsV3pXSWSzVQ2396WT65e2E or did:erc725:ropsten:2F2B37C890824242Cb9B0FE5614fA2221B79901E. In those cases the DID method namespaces are partitioned, but the DID methods are still v1 (not v1:test:nym) and erc725 (not erc725:ropsten).

Having said that, we may be able to improve the param-name ABNF rule to more clearly distinguish between generic and method-specific names, and reference the method rule in the latter case.

Does this make sense?

All 7 comments

@mitfik I don't think there is a contradiction. Yes we are saying that "DID method namespaces" MAY include colons. But this doesn't mean that the method name (the ABNF method) includes colons. In your example:

did:foo:baz:21tDAKCERh95uGgKbJNHYp;foo:baz:hex=b612

The DID method is foo. You could say that this DID method's namespace (= everything under did:foo) is further partitioned by colons, i.e. by baz:. But the baz: is already part of the method-specific-id, not part of the method.

Other real-life examples include did:v1:test:nym:UxYjr6F3hqwiF3yffplpcsV3pXSWSzVQ2396WT65e2E or did:erc725:ropsten:2F2B37C890824242Cb9B0FE5614fA2221B79901E. In those cases the DID method namespaces are partitioned, but the DID methods are still v1 (not v1:test:nym) and erc725 (not erc725:ropsten).

Having said that, we may be able to improve the param-name ABNF rule to more clearly distinguish between generic and method-specific names, and reference the method rule in the latter case.

Does this make sense?

Thanks @peacekeeper for clarification I think now I got it.

To put that in my words it would be:

We can use namespace within DID method so the method-specific-id and method-specific parameters may be partitioned hierarchically.

So if above is correct is just within the spec the wording which make it harder to understand as DID method refers to whole method like sov, peer but there is no clarity what means DID method namespaces. Base on that what you explained DID method namespaces are the namespace for method-specific-id and namespace for method-specific parameters (not necessarily coming from that method namespace) and not namespace for a method itself like did:namespace:method-name

If that all above make sens we can consider to clarify that as well within the documentation and/or close the ticket.

p.s.
I come across that problem while trying to write parser for DID url. So it could happen that people could understood it same way and try to implement namespace on method-name and not method-specific-id

@mitfik and @peacekeeper Having caught up with this issue, I see the problem. It is not with the ABNF, it is with the rule names we are using and the editorial text that explains the ABNF.

Since I believe DID namespacing is going to become more important than we originally thought, I am happy to suggest a revision to the ABNF that will not change the ultimate structure of a DID, but which will give us a consistent way to refer to multi-level DID namespaces. If you agree that will address the problem, let me know via reply and then I'll work up a PR.

@talltree I see one potential risk with changing the ABNF in that manner: If the ABNF is changed to more strongly emphasize the possibility of "multi-level DID namespaces", then we may give the impression that there are method-independent semantics and behaviors which are defined by the DID spec for all "levels" (colons). But in fact only the first and second colon are method-independent, any additional "levels" (colons) are method-specific.

Some methods use this syntax to indicate which chain/ledger to use, but other methods may have very different use cases for namespacing. So I actually like the fact that this is currently encapsulated inside the method-specific-id rule.

Perhaps if we want to change the ABNF, we can work on the method-* rules but leave the did rule the way it is now?

@mitfik do you still have any comments on this issue, or a proposed PR to fix/improve this? Otherwise I propose to close the issue.

@mitfik do you still have any comments on this issue, or a proposed PR to fix/improve this? Otherwise I propose to close the issue.

All good from my side. Thanks!

Actually I created PR https://github.com/w3c/did-core/pull/215 to address the last few comments in this issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rhiaro picture rhiaro  路  3Comments

brentzundel picture brentzundel  路  6Comments

dmitrizagidulin picture dmitrizagidulin  路  6Comments

oed picture oed  路  8Comments

DurandA picture DurandA  路  5Comments