search

w3c-ccg / did-method-web

DRAFT: did:web Decentralized Identifier Method Specification
https://w3c-ccg.github.io/did-method-web/
Other
32 stars 17 forks source link

User component of a URL #69

Open jernst opened 1 year ago

jernst commented 1 year ago

Consider https://foo:bar@baz.example. How is that supposed to be mapped?

If the user component is not permitted, document that explicitly. Alternatively make an example that shows how this is mapped.

gribneau commented 1 year ago

Plain text user and password are not supported. It is very unlikely that support will materialize.

jernst commented 1 year ago

If that's the intention, be clear about it in the doc. (I agree on the password part, but the user part could be convenient for some authenticated use cases.)

dmitrizagidulin commented 1 year ago

@jernst - I agree, the spec should state explicitly that user component of the URL is not supported. If you have a moment, a PR would be welcome! :)

jernst commented 1 year ago

I could do that, but I've been thinking ... and have come to disagree. The value of this spec diminishes very rapidly the more restrictions are being made on which URLs are supported. Instead I believe that the spec should support every possible URL, regardless if how strange or unlikely or misguided.

dlongley commented 1 year ago

@jernst,

The value of this spec diminishes very rapidly the more restrictions are being made on which URLs are supported.

Is that true? How do you know / why do you think so?

It may be important to especially consider the cases you provide in the next sentence:

Instead I believe that the spec should support every possible URL, regardless if how strange or unlikely or misguided.

What value is lost if a "misguided URL" is not supported? What about a "strange URL" or "unlikely URL"? Is the value of the spec "diminished very rapidly" in any these cases -- if so, how and why do you think so?

jernst commented 1 year ago

The value that's lost is that I have to think, and write special-purpose code, and potentially workarounds, instead of having a 100% complete mapping. I know because I tried to use the spec for something I'm developing and that has turned out to be a bad idea for these reasons.

P.S. It occurs to me now that perhaps this spec should not exist, and instead a spec should exist that explains how to discover a DID document from any valid http or https URL. Not clear what value is created by mapping (a subset! of) the https URL namespace into something that starts with did:web: if all one really wants is the DID document. (We did that mapping back in the day with Yadis, mapping to an XRDS document, which I guess is the ancestor of the DID document.)