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

Support "file" not just "directory" paths #68

Open
jernst opened this issue Dec 21, 2022 · 3 comments
Open

Support "file" not just "directory" paths #68

jernst opened this issue Dec 21, 2022 · 3 comments

Comments

@jernst
Copy link

jernst commented Dec 21, 2022

Consider https://foo.example/bar/baz.html.

  • Applying the algorithm, this leads to did:web:foo.example.com:bar:baz.html. Is that intended? If so, add an example to the doc. If not, be clear it shouldn't be. (I believe the entire URL path namespace should be mappable, perhaps even including parameters).
  • Applying the reverse algorithm, the DID document is supposed to be at http://foo.example/bar/baz.html/did.json. Is that intended, turning "file" baz.html into a "directory" all of a sudden? If so, please be clear about it. If not, document an alternative.
@gribneau
Copy link
Contributor

(I believe the entire URL path namespace should be mappable, perhaps even including parameters).

There hasn't been consensus in support of direct mapping as described.

What would baz.html contain?

If you intend to encode DID information within the HTML, perhaps as a JSON object definition in javascript, would it be easier to simply use the https URL?

@jernst
Copy link
Author

jernst commented Dec 21, 2022

The way I understand the intent of the path namespace in URLs is that no structure is assumed. The "file" vs "directory" distinction that we tend to make is entirely a convention that comes from many web servers directly mapping the path into a filesystem hierarchy. Ergo, the DID web spec should make no distinction between paths that end with slash or with .html. So I'm in favor of one of the alternatives that I'm outlining. It's just that the spec is silent about it and that lets people hallucinate what they thought the intent was, and that's usually not a good plan for specs ...

@gribneau
Copy link
Contributor

the DID web spec should make no distinction between paths that end with slash or with .html

The spec makes no distinction in that respect. The method specific identifier is colon delimited because people were uncomfortable with the use of the URI path. You can find the reason for this concern in DID core.

Do you have a specific use case in mind?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants