Orie Steele

I support option B. Possibly with a redundant entry for: application/ld+json with a profile, as is supported in activity pub today.

@tplooker this would be a breaking change for did web, but IMO something so simple may actually by worth it...

I think folks are expecting all interoperable did methods to support the same DID URL structures... here is an example: ``` did:example:123/path/foo?query=bar#fragment-baz ``` In did web today, this looks like:...

> I'll also mention the elephant in the room... application/json is not a valid media type for a DID Document... Very few developers are going to hardcode `application/did+ld+json` into their...

However, regardless of the underlying JSON document, I am in favor of simplifying resolution rules, so long as we don't loose interoperability with other did methods... We can forbid folks...

Here is a complete did:web resolver: ``` // specification const resolve = (did) =>{ const didToUrl = (did) => { const regex = new RegExp( `did:web:(?[a-zA-Z0-9/.\\-_]+)(?[a-zA-Z0-9/.:\\-_]*)` ); const match =...

Here is an example of using did web with GitHub https://github.com/OR13/signor

@gribneau certainly we would need to register it if we continue to use it. I don't think we loose any potential features by opting not to use `.well-known` URIs though......

I suggest we close this issue, the complexity is not worth it, and there are other DID Methods with better audit-ability for this use case.

I personally don't like the idea of attaching proofs to did:web.... I had done the same thing with did:github, and it made it super frustating to update.... we even tried...