-
Notifications
You must be signed in to change notification settings - Fork 99
Relative DID URLs #880
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
Comments
@FabioPinheiro what change would you like to see in the specification? Can you propose some concrete text? Based on my read of https://www.w3.org/TR/did-1.0/#relative-did-urls ... and 5.2, you coerce any relative value using the rules in section 3.2.2. IOW, I don't see what the issue is, can you specify exactly what problem it is that you are experiencing? |
believe there is another ticket and two PRs +- related with this. But basically I believe that in section 5.2 instead of |
BTW one of the PRs I was taking is here w3c/did-resolution#130 |
@FabioPinheiro do you agree that in DID Resolution this has been fixed by w3c/did-resolution#125 ? Then if I understand correctly, you are saying that here in DID Core we should also clarify that the value of |
yes In terms of examples, there is already one added by #860 (PR #874) before I open a issue. My problem is that the specification in 5.2 IMO (and I'm having some difficulties of having the current state of the document at the moment) we should specify/rename DID URL to Full DID URL and generalize the name DID URL to be either full or relative DID URLs. And then revisit the whole document to figure out if it should be using Full DID URL or a DID URL. |
I'm back you this question again. (Can't find previous discussions)
In
3.2.2
Relative DID URLs its mention how relative DID URLs look like that how it should be used. Examples are givenBut then they are incompatible with the rest of the specs...
Each library implement these on different ways there are incompatibilities.
It's been a pain trying to be interruptible. I cannot even open issues on the libraries because the issue comes from the specification.
In the 5.2 Verification Methods
In the 5.2.2 Referring to Verification Methods
In 5.2.2 Referring to Verification Methods
The text was updated successfully, but these errors were encountered: