Reorganize, streamline, and extend did:web. #42

[gribneau]

I've reorganized the document, extended the resolution logic, added server
configuration considerations, and updated RFC references.

There are still comments in this document referencing various issues, but I have
moved them to sections dedicated to discussing the issues raised. We should
reach a consensus on paths forward for these. I think most of them have been
resolved by simply recognizing (and calling out) the reality of resolution over
https and can be removed.

[dmitrizagidulin]

Suggested change

	slashes. Colons in directories and subdirectories MUST be percent encoded, if
	present, to avoid being translated into slashes. A filename MAY optionally be
	included as the final section of the colon delimited method specific identifier.
	slashes. A filename MAY optionally be included as the final section of the colon
	delimited method specific identifier. All path fragments (directories and
	filenames) MUST be percent encoded.

I think we should emphasize that all characters in path fragments are percent-encoded, not just colons.

[gribneau]

Colons are a special case. If a filename or path contains a literal :, that would be translated into / if not percent encoded.

If the colon was not our delimiter, it would not need percent encoding.

[dmitrizagidulin]

@gribneau

If the colon was not our delimiter, it would not need percent encoding.

Ah, we still would, though, because directory and file names can contain characters that are not allowed by the DID spec. So it's not just the colon.

[gribneau]

The : that appears in the domain segment of the method specific identifier in the case that a port is specified must be percent-encoded to avoid being rewritten as /.

e.g.

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

vs.

did:web:example.com%3A1443
---> https://example.com:1443/.well-known/did/

[dmitrizagidulin]

👍
Great work, @gribneau! Thank you.

[gribneau]

Within the context of this PR, I think it would be beneficial to address a number of issues that have been noted in the text of the specification with an eye to ensuring that our explicit handling of those issues is adequate to remove them from the text and close them.

These appear on lines 462, 466, 487, and 582.

That informational section is intended to address those issues (and others), and avoid making did:web something it cannot be without a dramatic increase in complexity. This method should support DID delivery by static webservers in the simplest possible fashion.

There is also an ongoing discussion about the language describing potential DNS vulnerabilities and mitigation in #45, and we could pick up #46 and #44 as well.

Ideally, I'd like this PR to clean up the text and clear out as many outstanding issues as possible.

[OR13]

I suggest we not co-mingle these changes with the other cleanups, also this is a breaking change that would make existing implementations non conformant... cc @kdenhartog

[mprorock]

+1 we need to break this apart into multiple PRs

[OR13]

I would prefer to see application/json as the only defined format first... and then attempt to address these other representations separately... too many changes in this PR.

[gribneau]

In #47, I reduced to application/json and application/did+json to preserve the logic of shifting to index files instead of hardcoded /did.json.

I also removed references to JSON-LD.

This presents us with a path forward to comfortably support other representations in the future without embracing the complexity today.

[OR13]

Let's split out the file system and content type changes from the rest of this PR.

I'm generally in favor of the changes but concerned we are doing too much at once, and especially worried about the interop and breaking changes associated with the proposed representation changes.

[mprorock]

We should break this apart, at least by grammatical cleanup, followed by any PRs that may introduce breaking changes

[mprorock]

+1 we need to break this apart into multiple PRs

[gribneau]

There is a clean PR at #47 reflecting feedback above.