Add Path Based Option for DID Config

[OR13]

Similar to how did web supports path based routing, it should be possible to say that a URL not an origin... is linked to a DID...

this would allow websites like github pages and any non DNS admins to use the spec.

[bumblefudge]

I vaguely remember at one discussion of DID:Web (maybe the IIW session on it?), someone mentioned domain-only as being a feature, not a bug, in that it provided a certain reduced scope (I can't remember if for parsing or for disambiguation) and that domains typically have security guarantees that paths don't. I suspect bringing in "path-based mode" might be a major change, and maybe origin-only mode and path-mode separately might be usefully distinguished, whether with a property/flag, or by doing path-mode in a separate spec? To avoid all did:webs being assumed to be (and treated as) interchangeable? Just spitballing here, not an active member of this project so take all my input with a big ol' salt lick 🧊 .

[OR13]

@bumblefudge did web supports path based DIDs.... http://did.actor/

currently did config does not support anything but web origins... meaning vendors who are service providers will be doing this:

customer-1.vendor1.example
customer-2.vendor1.example

customer-1.vendor2.example
customer-2.vendor2.example

instead of this:

vendor1.example/customer/1
vendor1.example/customer/2

vendor2.example/customer/1
vendor2.example/customer/2

The later requires DNS changes and is generally more secure, the former would work with off the shelf tooling (like the did actor github pages example I provided).

The proposal is not one or the other, its to support both, so that people don't automatically gravitate towards did web, because of how flexible it is.... which they will probably do anyway :)

[bumblefudge]

Oh wow, thanks for explaining! Didn't realize this. Not sure what the future life of this spec is, should we put it on the agenda for some future meeting at ID WG? is a version already cut?

[tmarkovski]

I assumed that paths can just be used with the current spec even, so thanks for clarifying. Definitely worth adding language to support paths.

[jceb]

Potentially related to #54

[jceb]

I assumed that paths can just be used with the current spec even, so thanks for clarifying. Definitely worth adding language to support paths.

Just for clarification origins consist of the protocol, host and port (see https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#definition_of_an_origin). The path and other parts of a URL are not included.

[jceb]

While I think that linking paths is valuable, we need to make sure that we continue to support claiming origins. Claiming an origin effectively means control over a service, potentially including the DNS name. Claiming a URL including the path has almost no attached meaning in Web2.0 where users get write access to services. As stated in #54, the semantics and discovery mechanism for claiming social media profiles are unique to each service.

@emg110 @JelleMillenaar @Oran-Dan what are your thoughts?