Add support for optional full path in the method specific identifier. #5

gribneau · 2019-12-03T16:19:22Z

This simple extension retains support for well-known URLs on bare domains and adds the option to specify a full path.

It implies that Dmitri's DID will be added to w3c-ccg.github.io.

did:web:w3c-ccg.github.io/dmitri/did.json

https://w3c-ccg.github.io/dmitri/did.json

dmitrizagidulin

👍 from me, thanks @gribneau! @awoie - does this addition work for you?

awoie · 2019-12-06T15:07:22Z

@dmitrizagidulin uPort is implementing an approach where they provide an indication in their UI that a selective disclosure request came from a particular domain, e.g., github.io.

awoie · 2019-12-06T15:11:01Z

@gribneau can you please provide the corresponding language in the security considerations section?

awoie

I see one issue with having full paths and we have to at least point that out under security considerations what could be dangerous about it. Resolving a did:web and verifying some piece of signed data would no longer proof that the did:web controller is the controller of the domain. In your example, you are the controller but proofing control of that did won't proof that you are under control of github.io.

dmitrizagidulin · 2019-12-06T15:31:59Z

@awoie good points, that stuff is important to consider.

So, I think that having paths does not necessarily increase security risk, in the sense of, it has very similar semantics as URLs do in general. For example:

Resolving a web DID without a path: did:web:example.com:

2 ways to discover the DID, a) through /.well-known/, and b) through DNS TXT record, right?
The security implication is that the did controller (given that they authenticate, with the appropriate key in the doc) controls the domain. (Or at very least, controls the /.well-known/ top level dir OR the DNS records.)

Resolving a web with a path: did:web:example.com/users/dmitri/did

The security implication is just that the did owner has control of just that directory, so it could be like a multi-tenant user profile thing.

I think developers are used to reasoning about the two kind of URLs? One that represents the organization that controls the domain, and the other just a given user on that domain?

gribneau · 2019-12-06T16:52:53Z

I've added a section in Security Considerations to indicate that full paths very probably indicate user control of keys rather than domain operator control of keys.

Does this meet the need @awoie ?

awoie · 2019-12-10T13:07:33Z

@dmitrizagidulin According to the DID spec, "/" is not in the range of method-specific-id

did                = "did:" method-name ":" method-specific-id
method-name        = 1*method-char
method-char        = %x61-7A / DIGIT
method-specific-id = *idchar *( ":" *idchar )
idchar             = ALPHA / DIGIT / "." / "-" / "_"

So, did:web:example.com/users/dmitri/did needs to be URL encoded like did:web:example.com%2Fusers%2Fdmitri%2Fdid.

awoie

Can you pls update the PR to address the URL encoding part: #5 (comment)

dmitrizagidulin · 2019-12-10T16:05:35Z

@awoie

According to the DID spec, "/" is not in the range of method-specific-id

Right right - so, in this case, the / is part of the DID Path actually, not the id.

gribneau · 2019-12-10T16:14:37Z

Percent encoding is pretty ugly.

method-specific-id = *idchar *( ":" *idchar )

We could use :, translate to /, and require percent encoding in the odd case that someone uses a : in a url.

How does that sound @awoie ?

dmitrizagidulin · 2019-12-10T16:16:34Z

@gribneau - wait, I don't think we need to encode at all. We're using it as a DID url path (like any url path)

gribneau · 2019-12-10T16:39:38Z

That's right - I recall looking this up.

https://www.w3.org/TR/did-core/#path

Example 7:

did:example:123456/path

We're using:

did:web:example.com/path/to/did.json

awoie · 2019-12-11T12:35:41Z

So, the DID will be `did:web:example.com`in both cases? I think that does not work for the following reason... Example 1: `did:web:github.com/scammerorganization/scammingdids/blob/master/did.json` Example 2: `did:web:github.com` That means that both refer to the same DID but they are clearly not under the control of the same entity. Would you agree with that? Oliver

…

On Tue, Dec 10, 2019 at 5:39 PM Christian Gribneau ***@***.***> wrote: That's right - I recall looking this up. https://www.w3.org/TR/did-core/#path Example 7: did:example:123456/path We're using: did:web:example.com/path/to/did.json — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=AKLN3MDKPK6FER6AGN4LZADQX7A4VA5CNFSM4JU2XCRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGP4XQY#issuecomment-564120515>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKLN3MG4F3OZ3VDXNWUONA3QX7A4VANCNFSM4JU2XCRA> .

awoie · 2019-12-11T12:41:58Z

@gribneau What problem do you want to solve with using the path notation? Regardless of the domain binding, I am asking because I am concerned that having the path version and the .well-known version of did:web will have two separate security guarantees:

did:web:example.com -> it is very likely that the did doc can only be updated by the owner of the domain, i.e., one entity
did:web:example.com/my/oliver/did.json-> the owner of example.com granted me access to that directory. We add another middle man (in addition to domain registrars) that could manipulate my did doc anytime.

They might even fall into two separate W3C DID method rubrics.

gribneau · 2019-12-11T15:51:52Z

What problem do you want to solve with using the path notation?

This thread began with a member of the public noting that most DID methods support resolution of many DIDs rather than just one.

I agree with that observation, and am trying to make it possible for a website to offer DID resolution for an arbitrarily large number of users.

did:web:example.com -> it is very likely that the did doc can only be updated by the owner of the domain, i.e., one entity

did:web:example.com/my/oliver/did.json-> the owner of example.com granted me access to that directory. We add another middle man (in addition to domain registrars) that could manipulate my did doc anytime.

The first example resolves to the DID document of the domain itself. The second example resolves to a DID document hosted on that domain, probably of a user.

I do not think any person with a technical background would confuse these identifiers:

did:web:example.com

did:web:example.com/alice/did.json

If the concern is that the DID Path is used inappropriately, we can make a very simple modification to resolve this.

did:web:example.com/alice/did.json

becomes

did:web:example.com:/alice/did.json

This would then be more consistent with the use of "should" in the DID Path definition, and requires a very minor adjustment.

They might even fall into two separate W3C DID method rubrics.

If the web method is intended to resolve precisely one DID document per domain, rather than supporting resolution of people's DID documents via the web generally (as it surely appears based on the nomenclature selected), I can create an alternative method.

Please advise @dmitrizagidulin @awoie .

dmitrizagidulin · 2019-12-12T16:13:16Z

@awoie

So, the DID will be did:web:example.comin both cases? I think that does
not work for the following reason...
Example 1: did:web:github.com/scammerorganization/scammingdids/blob/master/did.json
Example 2: did:web:github.com
That means that both refer to the same DID but they are clearly not under the control of the same entity. Would you agree with that?

Ok, so, we've got several things to unpack here.

One is - just like example.com/user/one and example.com/ are not the same URL, they would not result in the same DID. The authority part of the URL is the same, in each case, true. (Both in the did:web and regular url case). But the URL (and DID) is different.

Two - how do we deal with different URLs with the same authority part of the URL potentially representing different controllers / different trust levels? I would argue that this sort of calculation is built into the URL already. All developers and most users are familiar with the trust level difference of github.com/ and github.com/someorg/.
What's even more interesting, is - the type of sites that allow users to publish arbitrary content (like Github, and Wordpress), explicitly vary the authority depending on the user. Meaning, WordPress specifically puts user IDs into the authority part of the URL, to differentiate alice.wordpress.com and wordpress.com. Note that Github does this as well! You can't access a DID file just with a raw github URL, github.com/scammer-org/did. You can only access it via Github.io, which is very careful with the authority -- scammer-org.github.io/did.

We add another middle man (in addition to domain registrars) that could manipulate my did doc anytime.

Three - right, ok, so thirdly we have a concern about integrity protection of the contents of the DID Documents (can the web host mess with the contents whenever they want?). This is a legit concern, regardless of whether we allow paths to be a part of the did:web method or not. For this, we have to employ other mechanisms -- we can require (or strongly recommend) that the DID Document itself be signed by the controller. (Preventing tampering). And we can point to the Hashlink mechanism, so that people can refer to a particular version of the DID Document without any concern of tampering by the host.

gribneau · 2019-12-12T16:33:58Z

The three part breakdown from @dmitrizagidulin above raises issues that should be addressed, but I think it is worth noting that use cases for web resolution of many user DIDs are emerging in mainstream conversations, and this specification is very close to solving the basic user identity problem in a portable fashion.

Jack Dorsey announced yesterday that Twitter will fund development of open standards for distributed social media. This will require verifiable identity, and we can easily imagine platforms at the scale of Twitter generating DIDs per user to sign content that will be distributed arbitrarily.

For example, Jack's DID Identifier could be:

DID:WEB:twitter.com/jack/did.json

For a scheme like this to be practical, the specification would need to remain flexible enough to support either user control for platforms that place control of the DID document in the hands of the users, or platform control for use cases in which the platform creates and manages the DID documents but wishes to identify each user discretely.

I have no reason to believe that Twitter would necessarily go this route, but the use case presents itself clearly in Jack's announcement:

https://twitter.com/jack/status/1204766078468911106

dmitrizagidulin · 2020-03-05T18:49:32Z

Ok, so, we have two main obstacles here. One is technical/ABNF related, and one is conceptual (what sort of trust model are we trying to convey).

1) Technical Obstacle - ABNF

So, like @awoie pointed out, the current DID Core data model / ABNF rules for the DID uri does not allow the id attribute to have path (or query or fragment) components.
So, for example, currently this would not work:

did:web:example.com/users/dmitri/did.json

-> resolves to DID Document:

{
  "id": "did:web:example.com/users/dmitri/did.json",
  "authentication": [ ... ],
  // ...

^ that wouldn't work, because the Subject (identified by the id property) isn't supposed to have a path component.
(Although I brought this up as an issue in the DID WG - see my comment on #183.)

Potential solutions:

1.a): Campaign to change the DID Document data model / ABNC rules :)

1.b): Allow the did:web method to encode the path component of the https url in the authority segment of the DID.

So, an https URL of https://example.com/dmitri/did.json would be encoded as:

did:web:example.com%2Fdmitri%2Fdid.json.

(Although, as @gribneau points out, percent-encoding is kind of clunky, UI wise, but we could potentially think of some other encoding.)

2) Strategic/Policy Question - SHOULD we allow this at all?

Even more important than the previous item is of course the question "Is this a good idea at all?" (because it's a safe bet that if yes, we can solve obstacle 1)).

Part of the reason (I suspect) that @awoie and others are objecting to this PR, is that currently, we have a tidy trust model:

One domain (the hostname part of the URL) === One and Only One DID

So, the current implication is - a did:web url has the full support/authority of the domain behind it.

Which means that the current answer to "how do we provide DIDs for our users, on our web site" is "give them subdomains". (Especially since now, wildcard SSL certs are cheap, and Lets Encrypt allows wildcart certs for free.)

So here, the main question is - do we want to support multiple DIDs on a hostname (via some solution to item 1 above)?
And if yes, what's the justification - is it that giving users subdomains is prohibitive for some reason?

dmitrizagidulin · 2020-03-05T18:55:09Z

My current stance on that question 2) is - I'm not sure. I can see arguments for allowing multiple DIDs on the same hostname -- just due to IT Department difficulties with provisioning new SSL certs for subdomains.
For example, say a company wants to give DIDs to all of their staff, at did:web:bigcompany.com/staff/12345.json and so on. It might be a deal-breaker for some potential users to be able to provision a subdomain for each staff member.

Let's wait to hear from various implementers?

gribneau · 2020-03-05T19:17:11Z

I agree that we can find a solution to issue 1 if there is agreement on issue 2.

2) Strategic/Policy Question - SHOULD we allow this at all?

Even more important than the previous item is of course the question "Is this a good idea at all?" (because it's a safe bet that if yes, we can solve obstacle 1)).

Part of the reason (I suspect) that @awoie and others are objecting to this PR, is that currently, we have a tidy trust model:

One domain (the hostname part of the URL) === One and Only One DID

We do indeed have a tidy model linking a DID to a domain. The name DID:WEB, though, lends itself to a more expansive interpretation, as most sites have multiple users, and "identity" is more readily associated with persons that sites.

So here, the main question is - do we want to support multiple DIDs on a hostname (via some solution to item 1 above)?
And if yes, what's the justification - is it that giving users subdomains is prohibitive for some reason?

It is feasible to support potentially thousands of subdomains with wildcard certificates, but I think it is more likely that bigcompany.com would simply disregard this standard and do something simpler.

My position on the issue is that the specification would support many more use cases if we resolve many DIDs in each domain, and that this would enhance the value of the specification.

dmitrizagidulin · 2020-03-06T20:24:12Z

Since my previous comment yesterday, I've grown more convinced that this is a needed feature (to support multiple DIDs per hostname).

The ability to create subdomains is a fairly advanced skill set, considerably more so than just registering a domain name.

OR13 · 2020-03-06T20:45:12Z

Seems like its fine to do :did:web:example.com:/directory/subdirectory/ if you are enforcing the file name is did.json it does not need to included in the did... Pretty common in schools to see:

did:web:university.example.com:/student/~jsmith/

As for the concern over the trust domain issues, as long as :

did:web:example.com:/directory/subdirectory/ and did:web:example.com are different DIDs I think its fine to have one be domain admin and the other be student... obviously if you control the domain, you control 100% of did:web... regardless of which type of did you have... this is similar approach to what we took with Github DID... which you can see people are using by querying github: https://github.com/search?q=ghdid

https://github-did.com/api/v1/did/did:github:OR13

We convert the github username to a url to a file in a github repo...

You would be doing the same thing, just for websites other than github.

dmitrizagidulin · 2020-03-09T15:58:41Z

@OR13

Seems like its fine to do :did:web:example.com:/directory/subdirectory/ if you are enforcing the file name is did.json it does not need to included in the did

Agreed, yeah. Except we need to find a way to encode the slashes (due to the ABNF issue I mention above). And so far, I'm kind of liking the idea of using : (in the did authority segment) to encode slashes. So, specifically:

https://example.com/directory/subdirectory/did.json   ->  did:web:example.com:directory:subdirectory (did.json implied)

gribneau · 2020-03-10T13:59:16Z

@dmitrizagidulin

So, specifically:

https://example.com/directory/subdirectory/did.json   ->  did:web:example.com:directory:subdirectory (did.json implied)

This is quite close to one of my initial drafts. If there is a consensus on this approach, I'll be happy to resolve the conflicts and update the PR.

dmitrizagidulin · 2020-03-17T18:52:47Z

@awoie - Would you agree with this direction?

awoie · 2020-03-17T20:28:34Z

@dmitrizagidulin two things...

there seems to be consensus that the domain and path-style DIDs are two distinct DIDs and have different security guarantees (domain vs user). Is this correct? Can we please provide the two examples from @OR13 and provide explicit language that both DIDs are not equivalent.
Further, I think the examples still contain "/" in the method-specific-id. I believe there was an issue with that and the solution was to use ":" instead?

@mirceanis ^^

dmitrizagidulin · 2020-03-17T20:46:07Z

@awoie sounds good!

dmitrizagidulin · 2020-03-19T16:01:29Z

@gribneau - thanks for the updates! (Do you mind rebasing on the latest index.bs, so that there's no conflicts?)

@awoie -

there seems to be consensus that the domain and path-style DIDs are two distinct DIDs and have different security guarantees (domain vs user). Is this correct? Can we please provide the two examples from @OR13 and provide explicit language that both DIDs are not equivalent.

Correct. Does the language in the Optional path considerations section work, in terms of providing explicit language?

…3c-ccg#2

dmitrizagidulin · 2020-03-24T16:10:47Z

Thanks again to @gribneau for rebasing, and all your work on this, and thank you to @awoie for excellent discussion. Merging.

mirceanis · 2020-03-24T16:13:21Z

Besides the uPort/DIF implementation, what are other implementations that need to be notified of this change in spec?

dmitrizagidulin · 2020-03-24T16:16:27Z

@mirceanis Great question. I'm working on an implementation as well. The only other one I can think of is @peacekeeper's universal resolver?

mirceanis · 2020-03-24T16:18:51Z

@dmitrizagidulin, the uniresolver uses the uport driver which uses the implementation that is now hosted in DIF.

gribneau mentioned this pull request Dec 3, 2019

Support multiple DIDs per domain with a parameter. #4

Closed

gribneau changed the title ~~#2 Add support for optional full path in the method specific identifier.~~ Add support for optional full path in the method specific identifier. Dec 3, 2019

gribneau mentioned this pull request Dec 3, 2019

Fix URL of did.json #3

Merged

dmitrizagidulin approved these changes Dec 6, 2019

View reviewed changes

awoie self-requested a review December 6, 2019 15:11

awoie requested changes Dec 6, 2019

View reviewed changes

gribneau requested a review from awoie December 6, 2019 16:50

awoie requested changes Dec 10, 2019

View reviewed changes

dmitrizagidulin mentioned this pull request Mar 5, 2020

Add possibility to expose multiple identities under the same domain name #2

Closed

gribneau added 2 commits March 19, 2020 12:31

Add support for optional full path in the method specific identifier. w…

db8ee54

…3c-ccg#2

render revised index.html

0b68cd4

gribneau force-pushed the optional-full-path branch from 138aff5 to 0b68cd4 Compare March 19, 2020 16:34

dmitrizagidulin merged commit f676bf2 into w3c-ccg:master Mar 24, 2020

mirceanis mentioned this pull request Mar 24, 2020

Add support for full path in the identifier part decentralized-identity/web-did-resolver#32

Closed

dmitrizagidulin mentioned this pull request May 3, 2020

How to handle hostnames with ports? #7

Open

gribneau mentioned this pull request Dec 15, 2021

Use absolute file paths for did:web DIDs. #52

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for optional full path in the method specific identifier. #5

Add support for optional full path in the method specific identifier. #5

gribneau commented Dec 3, 2019

dmitrizagidulin left a comment

awoie commented Dec 6, 2019

awoie commented Dec 6, 2019 •

edited

Loading

awoie left a comment

dmitrizagidulin commented Dec 6, 2019

gribneau commented Dec 6, 2019

awoie commented Dec 10, 2019

awoie left a comment

dmitrizagidulin commented Dec 10, 2019

gribneau commented Dec 10, 2019

dmitrizagidulin commented Dec 10, 2019

gribneau commented Dec 10, 2019

awoie commented Dec 11, 2019 via email •

edited

Loading

awoie commented Dec 11, 2019 •

edited

Loading

gribneau commented Dec 11, 2019 •

edited

Loading

dmitrizagidulin commented Dec 12, 2019

gribneau commented Dec 12, 2019

dmitrizagidulin commented Mar 5, 2020 •

edited

Loading

dmitrizagidulin commented Mar 5, 2020

gribneau commented Mar 5, 2020

2) Strategic/Policy Question - SHOULD we allow this at all?

dmitrizagidulin commented Mar 6, 2020

OR13 commented Mar 6, 2020 •

edited

Loading

dmitrizagidulin commented Mar 9, 2020

gribneau commented Mar 10, 2020

dmitrizagidulin commented Mar 17, 2020

awoie commented Mar 17, 2020

dmitrizagidulin commented Mar 17, 2020

dmitrizagidulin commented Mar 19, 2020

dmitrizagidulin commented Mar 24, 2020

mirceanis commented Mar 24, 2020

dmitrizagidulin commented Mar 24, 2020

mirceanis commented Mar 24, 2020

Add support for optional full path in the method specific identifier. #5

Add support for optional full path in the method specific identifier. #5

Conversation

gribneau commented Dec 3, 2019

dmitrizagidulin left a comment

Choose a reason for hiding this comment

awoie commented Dec 6, 2019

awoie commented Dec 6, 2019 • edited Loading

awoie left a comment

Choose a reason for hiding this comment

dmitrizagidulin commented Dec 6, 2019

gribneau commented Dec 6, 2019

awoie commented Dec 10, 2019

awoie left a comment

Choose a reason for hiding this comment

dmitrizagidulin commented Dec 10, 2019

gribneau commented Dec 10, 2019

dmitrizagidulin commented Dec 10, 2019

gribneau commented Dec 10, 2019

awoie commented Dec 11, 2019 via email • edited Loading

awoie commented Dec 11, 2019 • edited Loading

gribneau commented Dec 11, 2019 • edited Loading

dmitrizagidulin commented Dec 12, 2019

gribneau commented Dec 12, 2019

dmitrizagidulin commented Mar 5, 2020 • edited Loading

1) Technical Obstacle - ABNF

2) Strategic/Policy Question - SHOULD we allow this at all?

dmitrizagidulin commented Mar 5, 2020

gribneau commented Mar 5, 2020

2) Strategic/Policy Question - SHOULD we allow this at all?

dmitrizagidulin commented Mar 6, 2020

OR13 commented Mar 6, 2020 • edited Loading

dmitrizagidulin commented Mar 9, 2020

gribneau commented Mar 10, 2020

dmitrizagidulin commented Mar 17, 2020

awoie commented Mar 17, 2020

dmitrizagidulin commented Mar 17, 2020

dmitrizagidulin commented Mar 19, 2020

dmitrizagidulin commented Mar 24, 2020

mirceanis commented Mar 24, 2020

dmitrizagidulin commented Mar 24, 2020

mirceanis commented Mar 24, 2020

awoie commented Dec 6, 2019 •

edited

Loading

awoie commented Dec 11, 2019 via email •

edited

Loading

awoie commented Dec 11, 2019 •

edited

Loading

gribneau commented Dec 11, 2019 •

edited

Loading

dmitrizagidulin commented Mar 5, 2020 •

edited

Loading

OR13 commented Mar 6, 2020 •

edited

Loading