I do think @dckc has a point, in that out of 20 DID Methods, the world will most likely settle on 2-3 of them (maybe).

The counterarguments that I can think of are:

• It may be helpful to developers to understand that all these sub-schemes are a part of the bigger DID scheme.
• We don't pollute the global scheme namespace (although, some would argue that is not a problem).
• Writing more general code that keys off of "did:" and sends those requests to a DID resolver is easier than keeping track of all of the schemes that should go to a DID resolver (simpler client code).

Just as important IMHO is establishing the DID scheme as a first-class type of new identifier in URI space. That not only establishes a fresh global namespace for DID methods, but it lets every piece of software that needs to install a URI handler for a new type of URI install one for handling DIDs.

That not only establishes a fresh global namespace for DID methods, but it lets every piece of software that needs to install a URI handler for a new type of URI install one for handling DIDs.

Playing devils advocate... one could argue that that piece of software would become very complicated vs. a piece of software only handling ONE scheme (vs. 20+ subschemes). We should pull @masinter into this discussion, as he was one of the editor's of the URI spec.

@masinter - thoughts? We're creating a new URI/URL scheme called "did:", that has some of the properties of the "URN" scheme. @dckc said you'd have some thoughts on this topic:

Primer on DIDs here:

https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/did-primer.md

@dckc,

There is no software that can handle the whole DID space; instead, each DID scheme needs its own handler.

It's possible that that may not always be true. By keeping all DIDs under a single root namespace, it enables the possibility for a common protocol in the future.

• I just started registering two schemes xmp.did xmp.iid
  https://www.ietf.org/mail-archive/web/uri-review/current/msg01926.html
  which bears some resemblance, and is already widely used

• I'm planning on submitting draft-masinter-dated-url
  https://tools.ietf.org/html/draft-masinter-dated-uri

I'm skeptical of any plan that requires widespread adoption before there's significant value.

A URI/URL/URN is just a string serialization of a data structure, which carries along with it some awkward encoding, parsing, i18n rules. Lots of times I think people go for a new ID when a new MIME type would be better

application/claim+json

When do you need a URI at all? You're really expecting href's to these things?

I was going to collect the bits and pieces of my feedback on this into a coherent whole... I went to the DID primer to find a typical usage story, but I don't see one.

I suggest StoryTellingAndTestCases.

When do you need a URI at all? You're really expecting href's to these things?

Yes, DIDs are actually URLs... you can retrieve them and get back a DID Document.

At present, there is no support/consensus in the community to remove the did: prefix. All DID URLs are expected to resolve to DID Documents that have very specific parsing rules. That is the thing that binds all DID-based URLs together and is the primary reason for the prefix.

Closing the issue as removing the did: prefix is unlikely to achieve consensus.

If this were a Working Group, I'd ask that my objection be carried forward, but I guess this is just a community group.

I see there's some confusion about this in the community:

The specification for DIDs is being created by the World Wide Web Consortium (W3C). -- Michiel Mulders January 28, 2018

Meanwhile, this community group doesn't have mandate to create URI schemes. I see did: is not in the registered schemes list. I looked for an issue tracking the registration; I don't see one.

If this were a Working Group, I'd ask that my objection be carried forward, but I guess this is just a community group.

Feel free to re-open the issue if you feel like there is something we could propose that would result in achieving consensus in the group. I would expect that the removal of the did: prefix would result in a large number of objections.

I see there's some confusion about this in the community

I'm not sure the person that wrote that is in the community. This is the typical confusion that folks seem to have around the difference of W3C CGs vs. WGs and CG Drafts vs. Rec-track specs. W3C has been trying to figure out how to message these things differently, but unfortunately, people just don't read the front matter of the spec nor understand how the standards process works.

this community group doesn't have mandate to create URI schemes.

I don't think any CG has a "mandate to create URI schemes" since they are non-normative, experimental things. That said, we should probably register the URI scheme provisionally since there are 6+ preliminary implementations so far. I've opened this as a separate issue: #73