Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistant namspace for method and/or method-specific-id #98

Closed
mitfik opened this issue Nov 6, 2019 · 7 comments
Closed

Inconsistant namspace for method and/or method-specific-id #98

mitfik opened this issue Nov 6, 2019 · 7 comments
Assignees
Labels
pr exists There is an open PR to address this issue

Comments

@mitfik
Copy link

mitfik commented Nov 6, 2019

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?

@peacekeeper peacekeeper self-assigned this Nov 6, 2019
@peacekeeper
Copy link
Contributor

@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?

@mitfik
Copy link
Author

mitfik commented Nov 13, 2019

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

@talltree
Copy link
Contributor

@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.

@peacekeeper
Copy link
Contributor

@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?

@peacekeeper
Copy link
Contributor

@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
Copy link
Author

mitfik commented Feb 26, 2020

@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!

@peacekeeper peacekeeper added the pending close Issue will be closed shortly if no objections label Feb 26, 2020
peacekeeper added a commit to peacekeeper/did-core that referenced this issue Mar 5, 2020
@peacekeeper peacekeeper added pr exists There is an open PR to address this issue and removed pending close Issue will be closed shortly if no objections labels Mar 5, 2020
@peacekeeper
Copy link
Contributor

Actually I created PR #215 to address the last few comments in this issue.

msporny added a commit that referenced this issue Mar 15, 2020
* Clarify use of colon in method-specific-id. Addresses #98, #152.
* Address comment by @davidlehn about use of colons.
* Use hyphen in "method-specific".

Co-Authored-By: Manu Sporny <msporny@digitalbazaar.com>
Co-Authored-By: David I. Lehn <dil@lehn.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr exists There is an open PR to address this issue
Projects
None yet
Development

No branches or pull requests

3 participants