Simplify did resolution, drop .well-known/ mechanism. #50

dmitrizagidulin · 2021-12-14T18:02:14Z

Based on the discussion in PR #47, and the consensus to simplify the DID-to-web-url translation rules by dropping the .well-known/ mechanism, and appending /did.json directly.

Previously:

did:web:example.com  --->   https://example.com/.well-known/did.json

Now (as of this PR):

did:web:example.com  --->   https://example.com/did.json

msporny

+1, I like the simplification here, and this also feels like it solves (or allows us to dodge) the debates on content negotiation.

msporny · 2021-12-14T18:21:37Z

index.html

+using the Koblitz Curve, and storing the <code>did.json</code> file in the root
+directory to represent the entire domain, or under the specified path if


Mildly concerned about this clause, but not enough to push back (yet).

msporny · 2021-12-14T18:22:34Z

index.html

@@ -293,7 +293,7 @@ <h3>
          </p>

          <pre class="example nohighlight" title="Creating the DID with optional path and port">
-did:web:example.com%3A3000:user:alice 
+did:web:example.com%3A3000:user:alice


Not going to argue in this PR, but I strongly feel that we should shift to this:

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

+1

I can live with that.

If we're going to simplify, we might as well take it all the way.

I have a roadmap item to support condensed representations at some point next year, but I can cross-reference .json via did:web with Also Known As for compatibility.

msporny · 2021-12-14T18:23:17Z

index.html

@@ -293,7 +293,7 @@ <h3>
          </p>

          <pre class="example nohighlight" title="Creating the DID with optional path and port">
-did:web:example.com%3A3000:user:alice 
+did:web:example.com%3A3000:user:alice


Suggested change

did:web:example.com%3A3000:user:alice

did:web:example.com%3A3000:user:alice.json

This PR is suggesting the above, right? If not, might object. Why aren't we just including file extensions?

No, the only reason that line is at all present in this PR, is that my code editor (correctly :) ) drops trailing spaces.

I'm not a fan of binding the representation to the subject identifier here either so -1 for me.

msporny · 2021-12-14T18:24:24Z

index.html

            </li>
            <li>
-Append <code>/did.json</code> to complete the URL.
+Append <code>did.json</code> to complete the URL.


Oh, hrm... this might be ok... really, we should just be telling people to do the whole file path. Why aren't we doing that?

We're not allowing whole file paths due to the rough consensus in the discussion of PR #47. See, specifically, Tobias's comment:

At this stage Im a -1 to any proposal that involves requiring the file extension to be leaked into the resulting did web identifier

I don't think we have rough consensus on that particular point -- this is what I mean, specifically: issue #52

let''s leave this to a separate issue/PR. I think we're going to need more time to resolve issue #52 faster than we can find consensus for this PR.

awoie

Want to understand why this change is really needed since it would break existing implementations.

awoie · 2021-12-14T19:08:53Z

index.html

@@ -274,7 +274,7 @@ <h3>

          <pre class="example nohighlight" title="Creating the DID">
 did:web:w3c-ccg.github.io
- -> https://w3c-ccg.github.io/.well-known/did.json
+ -> https://w3c-ccg.github.io/did.json


This is a breaking change to some deployments of did:web. Is this change really needed, or is this just beautification? .well-known is kind of an established pattern for things like this.

I agree that .well-known is an established pattern, but the consensus here is moving away from established patterns in favor of greater simplification.

Has anyone attempted to add the suffix to the IANA well known URI registry?

Consensus is moving away from established patterns while also breaking backward compatibility? The .well-known is not even visible in DID Docs, VCs etc. Why is this change needed? It doesn't simplify existing did:web implementations. In fact, those people would need to change the file location on their web hosts.

This is a breaking change to some deployments of did:web.

did:web is still an experimental specification in the CCG. Breaking changes are expected.

Why is this change needed?

To simplify the implementation of the specification and reduce the attack surface of the DID Method. It has become clear that the algorithms for mapping did:web URIs to file path locations are problematic for a number of reasons -- some people don't want to support content negotiation, some people don't want to support .well-known if they can get away from it, some think that not using regular paths was a mistake, etc. Now that there are more people implementing did:web, it's becoming clear that mistakes were made that should be fixed before the rest of the world picks the technology up.

That said, if there are huge deployments of did:web that we don't know about, there is probably a way to inject a compatibility layer into the specification, but the bar for putting those sorts of hacks into the specification should be high.

This is a breaking change to some deployments of did:web.

did:web is still an experimental specification in the CCG. Breaking changes are expected.

Fair enough.

Why is this change needed?

To simplify the implementation of the specification and reduce the attack surface of the DID Method. It has become clear that the algorithms for mapping did:web URIs to file path locations are problematic for a number of reasons -- some people don't want to support content negotiation, some people don't want to support .well-known if they can get away from it, some think that not using regular paths was a mistake, etc. Now that there are more people implementing did:web, it's becoming clear that mistakes were made that should be fixed before the rest of the world picks the technology up.

Just wondering, why is .well-known increasing the attack surface?

That said, if there are huge deployments of did:web that we don't know about, there is probably a way to inject a compatibility layer into the specification, but the bar for putting those sorts of hacks into the specification should be high.

I'm not aware of a huge number of did:webs in production.

The impact is a deployment problem that's going to leave many non technical people clueless to why they're unable to verify passes that worked yesterday.

What would cause them to be unable to verify passes that worked yesterday? Why can't you keep the did:web file in the same location as it existed yesterday AND serve it from the new location? Wouldn't this enable full backwards compat for your deployment base?

To be perfectly clear -- I expect everyone here is taking this seriously and we absolutely do not want to break MATTR/NZ's deployment. All we need to do is figure out a path forward that doesn't break the deployment AND fixes some of the issues w/ did:web.

Note that Apple devices are somewhat famous for creating problems with 30x responses. Verify the best practice if using a redirect - I think it was 307 the last time I checked.

(An internal rewrite is cleaner from a client perspective.)

Why can't you keep the did:web file in the same location as it existed yesterday AND serve it from the new location?

If we let webservers be web servers, this conflict is easily resolved.

For example, the rewrite rule below will cause nginx to return the same file for the two common URLs that have been discussed.

rewrite ^/.well-known/did.json$ /did.json last;

oh duh! 🤦 Sometimes it's the simplest things that I forgot about. I think the redirect solution could be a simple and low impact (we'd still have to update a few things) change that I think could work. Let me check with others about if they're alright with this. It's going to take some time to build the consensus though so please bare with me while I check with others.

You can do a redirect (307) that instructs the client to request the revised URL. This will work or fail depending on the client.

The webserver can also be configured with an internal rewrite that returns the DID file on an alternate URL, so that it appears at both URLs. I would recommend the internal rewrite as it is less risky.

tplooker

I'm away on leave today but just wanted to drop in a quick review to say that I'm -1 to this proposal at this stage for the following reasons

well known as a convention in part exists to create a dedicated namespace for well known resources to be published that do not risk polluting or closing off the root namespace of a domain. Therefore removing this looses that feature.
I've not seen an explanation on how hosting the document under a "well known" path could lead to security issues. And to the contrary if the argument is around implementation complexity then I'd say this pr + suggestions documented in Use absolute file paths for did:web DIDs. #52 creates a far more flexible but also complex syntax supported in did:web which hence is likely to have negative implications around security

OR13 · 2022-03-24T17:51:45Z

There are conflicts and objections, I suggest reopening this PR once they are addressed.

Simplify did resolution, drop .well-known/ mechanism.

891869e

dmitrizagidulin requested review from msporny, kdenhartog, mprorock, awoie and OR13 December 14, 2021 18:02

msporny reviewed Dec 14, 2021

View reviewed changes

dmitrizagidulin mentioned this pull request Dec 14, 2021

Remove the .well-known resolution rule #49

Open

awoie requested changes Dec 14, 2021

View reviewed changes

tplooker suggested changes Dec 17, 2021

View reviewed changes

OR13 closed this Mar 24, 2022

clehner mentioned this pull request Mar 24, 2022

Register Well-Known URI #58

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplify did resolution, drop .well-known/ mechanism. #50

Simplify did resolution, drop .well-known/ mechanism. #50

dmitrizagidulin commented Dec 14, 2021

msporny left a comment

msporny Dec 14, 2021

msporny Dec 14, 2021

gribneau Dec 14, 2021

msporny Dec 14, 2021

dmitrizagidulin Dec 14, 2021

kdenhartog Dec 17, 2021

msporny Dec 14, 2021

dmitrizagidulin Dec 14, 2021

msporny Dec 14, 2021 •

edited

Loading

kdenhartog Dec 17, 2021

awoie left a comment

awoie Dec 14, 2021

gribneau Dec 14, 2021

awoie Dec 15, 2021 •

edited

Loading

msporny Dec 15, 2021 •

edited

Loading

awoie Dec 16, 2021

msporny Dec 16, 2021 •

edited

Loading

gribneau Dec 16, 2021

gribneau Dec 16, 2021

kdenhartog Dec 17, 2021 •

edited

Loading

gribneau Dec 17, 2021

tplooker left a comment •

edited

Loading

OR13 commented Mar 24, 2022

		using the Koblitz Curve, and storing the <code>did.json</code> file in the root
		directory to represent the entire domain, or under the specified path if

	did:web:example.com%3A3000:user:alice
	did:web:example.com%3A3000:user:alice.json

Simplify did resolution, drop .well-known/ mechanism. #50

Simplify did resolution, drop .well-known/ mechanism. #50

Conversation

dmitrizagidulin commented Dec 14, 2021

msporny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msporny Dec 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

awoie left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

awoie Dec 15, 2021 • edited Loading

Choose a reason for hiding this comment

msporny Dec 15, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msporny Dec 16, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdenhartog Dec 17, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tplooker left a comment • edited Loading

Choose a reason for hiding this comment

OR13 commented Mar 24, 2022

msporny Dec 14, 2021 •

edited

Loading

awoie Dec 15, 2021 •

edited

Loading

msporny Dec 15, 2021 •

edited

Loading

msporny Dec 16, 2021 •

edited

Loading

kdenhartog Dec 17, 2021 •

edited

Loading

tplooker left a comment •

edited

Loading