Should the Aries Community DID be under did:aries, did:github, or https (rather than did:sov)?

[troyronda]

From the discussion on #115

https://github.com/hyperledger/aries-rfcs/pull/115/files#r304002908

If the "magic" DID were a peer DID (or another non-globally resolvable namespace), there could be an RFC that defines both the did:peer:id along with the associated DID document (to allow for resolving service endpoints). Aries implementations could include that magic "DID" and DID document, as defined by the RFC. Implementations could update this DID/DID document as the RFC evolves.

[swcurran]

Just to confirm - does the indirection proposed still support machine traversal to find a machine (and human) specification of the protocol? I think we should continue to have that as a long term goal.

[dhh1128]

@swcurran Yes, sort of. :-) The DID doc for this peer DID could list a service endpoint that points, for example, to the Aries RFCs repo. The problem is that such a DID doc would not be discoverable. What we could do is publish the DID doc as an RFC of its own. This is a bit weird; it's a "public" and "anywise" peer DID. The peer DID spec actually talks about why this is weird: https://openssi.github.io/peer-did-method-spec/#comparison (second paragraph). But although being odd, it's perfectly legitimate and it totally works.

[dhh1128]

@troyronda I am in favor of this change and would volunteer to make it happen in RFCs if you can get some other voices to agree.

[dhh1128]

An alternative to using did:peer would be to use did:git... This might make some sense for a community that is git-oriented.

[troyronda]

@dhh1128 Agree that conceptually a did:git for a git-oriented community has a nice semantic feeling to it. I am in favor.

(note: I'm not overly familiar with the specifics of the did:git method)

[llorllale]

I think git would align it too closely with the did:git method.

Why not reserve aries as a method and list it in the registry? (can't list in registry as it would have to conform with the requisites for did methods)

[dhh1128]

@llorllale Creating a did:aries method sounds great. However, as someone who's written a DID method spec, I am not eager to volunteer. You could probably do an adequate job with a page or two of text. Want to write the doc?

[llorllale]

@dhh1128 does it have to be respec? If so, where?

[dhh1128]

No, it doesn't have to be respec. It could just be an Aries RFC.

On Wed, Jul 17, 2019 at 6:28 PM George Aristy notifications@github.com wrote:

@dhh1128 https://github.com/dhh1128 does it have to be respec? If so, where?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/129?email_source=notifications&email_token=AAQ3JCDDPHTBI6T5IT6WHO3P762KRA5CNFSM4IERLX72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2G622Y#issuecomment-512617835, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ3JCDGOX2MNKZGIOFC7GLP762KRANCNFSM4IERLX7Q .

[troyronda]

@dhh1128 @llorllale I like the idea that the protocol messages use a type URI containing "aries". This, of course, can be accomplished via did:git or a new did:aries method.

I thought the did:git concept was a good idea since the community distributes both specs and implementations from its canonical git repository anyways.

@llorllale Would your aries DID method idea do something similar? (generically along the lines of distributing protocol metadata for a community?) Perhaps you could elaborate on the differences/pros/cons?

In any case, I think it is valuable to remove the need for a special ledger-based DID method from the protocols (and to @dhh1128 comments mitigate the perception & did document maintenance issues).

[swcurran]

I don't understand what did:aries would be. Is it being created strictly for the purpose of protocal message types? That seems like a lot of overhead for a minimal purpose.

My $0.02CDN is that we stick to something global and if not, we go with did:git (which may itself be global - in which case I'm totally behind it).

I'm definitely against creating something artificial for this use case. Dog food it.

On Thu, Jul 18, 2019 at 1:56 PM Troy Ronda notifications@github.com wrote:

@dhh1128 https://github.com/dhh1128 @llorllale https://github.com/llorllale I like the idea that the protocol messages use a type URI containing "aries". This, of course, can be accomplished via did:git or a new did:aries method.

I thought the did:git concept was a good idea since the community distributes both specs and implementations from its canonical git repository anyways.

@llorllale https://github.com/llorllale Would your aries DID method idea do something similar? (generically along the lines of distributing protocol metadata for a community?) Perhaps you could elaborate on the differences/pros/cons?

In any case, I think it is valuable to remove the need for a special ledger-based DID method from the protocols (and to @dhh1128 https://github.com/dhh1128 comments https://github.com/hyperledger/aries-rfcs/pull/115#discussion_r304017482 mitigate the perception & did document maintenance issues).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/129?email_source=notifications&email_token=AAHYRQVCLT4UI677EQAKLRDQADKIXA5CNFSM4IERLX72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JYLGQ#issuecomment-512984474, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHYRQUJOLAO647FJQQJXMTQADKIXANCNFSM4IERLX7Q .

[llorllale]

Let's first step back and think about what we want from this "DID method spec". Do we want full CRUD capabilities, or just limited Resolve capabilities? If the latter, this could be as simple as an RFC that binds a magical did:aries:BzCbsNYhMrjHiqZDTUASHg DID to a DDO that defines a serviceEndpoint with this repo's http base url. Protocol identifiers would look like:

{
    "@type": "did:aries:BzCbsNYhMrjHiqZDTUASHg;service=spec/didexchange/1.0/invitation"
    ....
}

... where did:aries:BzCbsNYhMrjHiqZDTUASHg;service=spec would resolve to a serviceEndpoint in the magical DDO with URL https://github.com/hyperledger/aries-rfcs or similar. The did-exchange protocol's full dereferenced URL above would be https://github.com/hyperledger/aries-rfcs/didexchange/1.0/invitation (or something similar).

I'm assuming all we want is simple resolution, hence no need to define a full blown method specification. Am I wrong?

[dhh1128]

I think I agree, but I can't resist pointing out some possible fanciness.Given that this DID will be used in every DIDComm message that ever gets sent, maybe it should be short. What if we made it a bit like did:git, but simpler:

1. We create an RFC that defines the did:aries method. In the folder for that RFC, next to the readme, we allow the checking in of any file with extension .diddoc.

2. Any such files create dids.

3. The value of the DID should be short. I suggest a random 16-bit number. This gives us plenty of possible did values, but all of them are only 4 chars long. These values should be embedded in the file, but also should be the names of the *.diddoc files.

4. Updates and deletes are just commits to the individual docs.

5. Right now, we don't define any keys. The security on the DID docs is the RFC vetting process for the repo. If we decide we want keys in the future, we can always update the docs to give them keys.

This would be dead easy to describe and implement, and I think it would meet all of our needs.

On Thu, Jul 18, 2019 at 5:21 PM George Aristy notifications@github.com wrote:

Let's first step back and think about what we want from this "DID method spec". Do we want full CRUD capabilities, or just limited Resolve capabilities? If the latter, this could be as simple as an RFC that binds a magical did:aries:BzCbsNYhMrjHiqZDTUASHg DID to a DDO that defines a serviceEndpoint with this repo's http base url. Protocol identifiers would look like:

{ "@type": "did:aries:BzCbsNYhMrjHiqZDTUASHg;service=spec/didexchange/1.0/invitation" .... }

... where did:aries:BzCbsNYhMrjHiqZDTUASHg;service=spec would resolve to a serviceEndpoint in the magical DDO with URL https://github.com/hyperledger/aries-rfcs or similar. The did-exchange protocol's full dereferenced URL above would be https://github.com/hyperledger/aries-rfcs/didexchange/1.0/invitation (or something similar).

I'm assuming all we want is simple resolution, hence no need to define a full blown method specification. Am I wrong?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/129?email_source=notifications&email_token=AAQ3JCDFN3Q6J5UZ2PY5M4DQAD3GJA5CNFSM4IERLX72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2KDLMA#issuecomment-513029552, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ3JCETDHS6VN3RDNVSWNLQAD3GJANCNFSM4IERLX7Q .

[llorllale]

@dhh1128 what would we gain with all those did docs?

[vinomaster]

@dhh1128 I am also confused. I see this topic related to the concept of a Decentralized DID Namespace Registry that would address network of network registration and discovery in a scalable decentralized manner. This topic has been discussed under the umbrella of the OpenSSI/ToIP activities and has been waiting for a proper place to propose an RFC. I am not sure if Aries is that place. If it is I will gladly submit a proposal.

[dhh1128]

The ability to have lots of docs/lots of dids in a did:aries method is of questionable value. I said I "[couldn't] resist pointing out some possible fanciness". It's my weakeness as an architect that sometimes I overbuild.

I do think it's possible that Aries might want more than 1 DID (e.g., one for testing, one for production, one for interop). What I proposed would give us no ceiling on the number of dids, but would still be dead simple. I suspect we could write a spec that had less features, but its description as a doc and its implementation in code wouldn't be any simpler than what I just described. So I was just pointing out the smallest possible move that would give us the greatest possible power as far as DID creation is concerned. You can do something different if you like, if you're writing the spec.

@vinomaster I don't think this is related to the DID namespace registry at all. We are just talking about the value that goes in the front of a type string in all DIDComm messages. Today it's "did:sov:something", and George is exploring replacing it with "did:aries:1" or something equally terse and equally decoupled from Sovrin. To do so, we have to choose a new DID method, or write our own (the current preference). I think the proposal is a good thing.

It's still worth writing an RFC about the DID namespace registry, and you may or may not want to do it as an Aries RFC--but that's a separate topic.

[dhh1128]

Wow. Notice how the did:aries:1 string in my above comment got rewritten by the markdown engine into a fancy graphic...

[llorllale]

@dhh1128

I think we are in agreement on points 1-4. I'll start typing the RFC up.

I think I agree, but I can't resist pointing out some possible fanciness.Given that this DID will be used in every DIDComm message that ever gets sent, maybe it should be short. What if we made it a bit like did:git, but simpler:

1. We create an RFC that defines the did:aries method. In the folder for that RFC, next to the readme, we allow the checking in of any file with extension .diddoc.

2. Any such files create dids.

3. The value of the DID should be short. I suggest a random 16-bit number. This gives us plenty of possible did values, but all of them are only 4 chars long. These values should be embedded in the file, but also should be the names of the *.diddoc files.

4. Updates and deletes are just commits to the individual docs.

5. Right now, we don't define any keys. The security on the DID docs is the RFC vetting process for the repo. If we decide we want keys in the future, we can always update the docs to give them keys. This would be dead easy to describe and implement, and I think it would meet all of our needs.

[llorllale]

@dhh1128 @troyronda @swcurran

I'm still grappling with one basic requirement for this new DID method: how decentralized do we want it to be? Does it have to be decentralized?

My immediate (and perhaps naive) thoughts were that it does not need to be decentralized at all. I think Daniel's proposal sort of points in the same direction as well (because the value of the DID is short), but please correct me if I'm mistaken.

I've talked with Troy at length regarding this - he's of the opinion it would be best if in the long run it is a fully decentralized method. I'm not sure if Stephen means the same when he says "it must be global".

I'm sympathetic to Stephen's point about the overhead. If we really want this to be decentralized then maybe we should use did:git, although it looks to me like the tooling is not usable yet (status). So right now the point about overhead goes both ways, contingent upon how fancy we want this method to be.

[swcurran]

My key points on this:

• Our goal should be that anyone in the world should be able to look at the @type of a message, get the DID, resolve that to a DIDDoc and from there to a human and machine consumable spec.
  • We don't have that today, but the idea of using a DID was that eventually we could do that.
  • As such, not having tooling today is not a great detractor - the current DID we are using for "core" message types is a DID that is known to only one person, and does not yet allow resolution and discovery of specs.
• I'm personally against creating (seemingly) random DID methods, so while I see this is a reasonable, special purpose case, I think it encourages others to create DID Methods that just make the world more complicated. Or more specifically, universal DID resolvers more complicated.

If we are going to change to something "neutral", I would look at did:git (but I haven't yet, so I don't know if it does what we need).

[dhh1128]

I agree with both George and Stephen. :-)

I would say that the amount of decentralization we need should match the amount of decentralization in the community that the DIDs represent. That doesn't have to be global, ultra decentralization, because this isn't a general-purpose DID. But it should at least match the idea of repo maintainers and community calls jointly managing the evolution of state in a repo.

I don't care very much about mature tooling, but I DO care about a mature spec that doesn't change on us. If we can manually create one did:git right now, and we are confident that did:git is not going to evolve in a way that disrupts all of DIDComm by changing the format of the DIDs and requiring every agent in the world to update its software as a result, then not writing a new DID method might make sense. But:

• We need an answer NOW, not in 3 months, because we need to change a bunch of protocols and message types asap.
• Shorter DIDs are somewhat better, all else being equal (as in the case of @type in a DID Exchange invitation).

[llorllale]

Looked into did:git a bit more closely - it is not motivated by a desire for the storage of arbitrary DIDs.

Their motivations:

• Cryptographic Signing of Git Commits is Broken
• In-band Identity Management
• Intellectual Property Provenance
• Verifiable Claims Against Open Source Contributions

Looking at their CRUDs and directory layout reflects their motivations: the only DIDs created are one for each contributor and one for the repo itself.

The mental model does not fit: we would be shoehorning our requirements into did:git if we start viewing protocols as "Collaborators" of this repo.

did:git is orthogonal to what we're aiming for. It can be implemented in this repo later on, but for a completely different purpose.

Protocols are not identities - they're a set of contracts and docs that require governance by identities. What we need are machine-resolvable contracts and docs.

[dhh1128]

Okay, @llorllale, that convinces me that we need did:aries. I am now a bit less overwhelmed than I was when you first proposed that idea, and I wouldn't mind taking a crack at a spec for it. If you've already started, keep going. But if you haven't started writing the doc, do you want me to create a strawman on hackmd that we can work on together?

[llorllale]

@dhh1128 I haven't done much yet. I think hackmd would work better for feedback from the community as opposed to a PR, so let's go for that.

[swcurran]

Thanks for looking at that @llorllale - I was guessing it wasn't going to be exactly right.

OK - I can live with did:aries and like the approach that Daniel has sketched out. Let's see if we can make it work.

[dhh1128]

Okay, @swcurran and @llorllale , what do you think of this? https://hackmd.io/@dhh1128/SyW5G6gXS

[troyronda]

@dhh1128 Suggest clarifying that the type of the repo is git (or otherwise updating the instructions to make GitHub compatible Web calls). (so that the implementor formally knows how to navigate to the path in the repo. e.g, /dids).

More concretely, I don't think this instruction works as-is via pure HTTP call (with the specified repo URI for Aries Community): "Compose the fully qualified resolution URI for the DID doc by combining repo-URI, path, and the name component of the DID. Append the file extension .diddoc."

I created a GitHub repo to demonstrate. https://github.com/troyronda/mydiddocs/dids/1.diddoc [does not work]. https://raw.githubusercontent.com/troyronda/mydiddocs/master/dids/1.diddoc [works]. https://troyronda.github.io/mydiddocs/dids/1.diddoc [via GitHub Pages]

[troyronda]

@dhh1128 Another consideration for the implementor relates to the release process. In particular, should READ operations:

• use the master branch;
• use the latest tag or latest tag under a particular semantic version or specified tag or HEAD;

Suggest including this information in the spec for each repo in the table.

[troyronda]

Side-note: there are some advantages to including some git semantics.

• branch and versioning to enable release processes (see previous comment).
• ability to clone the entire set of DID document locally.
• ability to distribute authenticity information independently (due to git and a release process, the repo is trusted up to a commit ... this information is distributed in the community; meaning mirrors outside GitHub can potentially be used).
  • as an aside, one could maybe eventually add a singing process similar to what did:git uses. This way the repo contents can be trusted from a certain commit, instead of up to a certain commit.

p.s., I think the current & most important step is to get to a spec that has a long-term Aries DID method string that pulls the DID documents from the repo as you have done @dhh1128. Thanks again for getting this out!

[dhh1128]

Thanks for the feedback, @troyronda !

My intention was not to limit this to github or git, but to tolerate any source code control mechanism. But I can see how that breaks my instructions about fetching a DID doc...

I hadn't thought about the branching issue at all. And great point about local cache.

I'm going to go update the hackmd doc to try to incorporate your ideas--but I might not do it to your satisfaction. Please do one more skim through, and leave comments directly in the hackmd doc if it needs more tweaks. (Everyone should be able to comment. If you sign in, you should be able to directly edit.)

[dhh1128]

Okay, @troyronda , I did an update pass. I think I added everything you suggested, except for the idea of versioning/tagging. I had two reasons why I left that out:

1. I have an approximate idea of what you're thinking, but I'm not confident of the details. So I'd like clarification or examples from you.

2. There is already the possibility of versioning built into the DID spec through matrix parameters and query strings. I was imagining that we could use this mechanism to request a particular version of a DID Doc by using version=<commit hash> or version=<tag> -- not as part of the DID value proper, but as a matrix parameter passed to the resolver. I am not confident that it's a good idea to build it into a DID method in a new way. However, I'd like to understand your thinking better, and probably discuss with @peacekeeper and/or @talltree.

[llorllale]

Yep - that's definitely fancier than what I had in mind. It's even reusable (my version wasn't).

[troyronda]

@dhh1128 The concepts LGTM. Thanks for incorporating the suggestions.

I think it would be great to use the DID spec's versioning semantics. (but I'm not familiar with the details nor implications.)

The remaining point would be about handling stability of the document itself. With versioning semantics coming from within the DID document, an accidental edit (& commit) could still make them unstable. This could be partially mitigated by sufficient CI testing and maintainer discipline... But we should additionally consider having stable branch for the DID docs that is mutated less frequently than master (e.g. with some "release"-like process).

[swcurran]

I've added my thoughts in the hackmd comments, notably:

• the scope IMHO is off in that it doesn't talk about the actual use case we want this for - namespacing for protocols and specification discovery.
• I don't see a need to make this general purpose as I can't see anyone else ever using it, but if we think others will want to use it, I would recommend not calling it "aries". did:name?

Other comments:

• I think we need to add how this is going to be used. This doc covers the mechanics of how it will be used, but is disconnected from the use case. How does this get us to namespaces for protocols and discovery of DIDComm protocol specifications?
• Since this is about DIDComm protocols - should it be "did:didcomm" or "did:comm"? Again, that will eliminate anyone else from being interested in using it.
• If we think of the primary (only?) use case for this (protocol naming), I think the branching issue is questionable. Are you really going to put into a message that it's type is based on a particular branch in the spec. repo? If you are going off what is in the message to discover it's spec, without the branch information you can't resolve to anything other than a single value - e.g. master. On the other hand - in the DIDDoc, you could have a service entry point that points to whatever you want for the spec - including that it is in a particular branch of a repo.

I'm questioning my alignment with/understanding of this approach. Is it about namespace and specification discovery?

[dhh1128]

Maybe we ARE misaligned...

I think the problem we're trying to solve is how to give an identity to a community--specifically, to the collective participants in Hyperledger Aries RFCs--in a way that doesn't bind the community to some other identity that's controversial (e.g., to an Ethereum or Sovrin or Veres One DID). We will use that identity to namespace protocols, but we could also use that identity to sign code artifacts, or to publish blog posts, or communicate securely with hackers who report a security vulnerability, or to officially announce that the community is disbanding, or whatever.

I don't understand why discovery is related at all. How does the format of the prefix in a protocol identifier aid in discovery? Are you thinking that all protocols that begin with an Aries DID are automatically assumed to be documented in the Aries RFCs repo? I'm not assuming this would be a hard-and-fast rule, though there'd probably be a strong correlation.

As soon as I started writing this method, I realized that it could be used outside Aries. The Indy and Ursa projects, at least, could really benefit. They have their own communities that overlap to some degree, but that are logically independent. Those communities won't be writing DIDComm protocols (maybe), but will be writing RFCs and could need to sign code, interact securely around vulnerability reports, and so forth. The DIF could use this, too--it's totally neutral about all the controversial stuff in our circles. The ToIP community that John J's so excited about could benefit. Etc.

I kept the name "aries" for the method because it is the Aries project that's defining and publishing it, and hosting the list of resolvable repos--NOT because it's limited to Aries use. Maybe that was a mistake. However, I'm not liking any alternatives yet. Maybe "did:repo", since its defining characteristic is that DID Docs are published in a repo and represent the community behind that repo?

[swcurran]

Interesting - that does make the current document easier to understand.

I use the term "discovery" meaning a path to finding the specification of a message. When I start development on an Aries agent, I might use the test suite to find the core messages I need to support. Over time, when my agent discovers messages it doesn't understand from other agents (perhaps a higher level version), I can find the spec for the version from the type string. I thought that was the key use case.

I don't think that all protocols used in Aries agents are documented in the Aries RFC repo, but I do think that I can add DIDDoc to the Aries RFC that includes a pointer to where the specification can be found. Basically, this is providing two layers of redirection - from the "repo table" to the DIDDoc holding space, and from each DIDDoc to where ever the specs/assets are stored. So indy-catalyst team might add it's own DIDDoc to Aries-RFC and have it point to a place where it's custom protocols are specified.

If the goal is to entice others to use this mechanism, definitely think it needs another name. "repo" is bland :-) but I don't have another that is descriptive and short. That said, I would think it would be hard sell - it's pretty complicated.

The other potential uses are nice and it's great if they work out, but I think we should optimize for the primary use case. Making it harder to use for the primary use case won't help. I think it's bad in the long term if we don't make it easy to add namespaces and find specs.

[troyronda]

I can see the logic behind either choice for the did method naming, and @dhh1128 described the rationale well. Keeping the mechanism generic enough to allow for potential reuse seems like a good idea to me.

I don't think having a table that creates "sub-namespaces" is adding much initial implementation complexity. We would hard-code those repo parameters from a table in any case (URI, Branch, Path). Having the additional mnemonic in the did prefix gives us more future-proofing and flexibility.

[llorllale]

@dhh1128 if you want to generate proofs, then maybe we should take another look at did:git...

[llorllale]

Btw, I think Troy's point here is very important - if we want resolvable specs then we need a release process (aka. versioning, stable branch, etc)

[swcurran]

I"m not so sure - which is why I think focusing on the use case is crucial. We have built into the protocol type string explicit versioning. Building versioning into the resolution would only add versioning of the DIDDoc, not of the specs pointed to by a specific DIDDoc. Further, I don't know how you would tell someone resolving the DID that they should use a specific git/GitHub version.

[troyronda]

@swcurran My above stability suggestion is to consider introducing a stable branch in the repo -- to allow for better release controls for these resolvable documents. This changes the cell that contains "master" (in Resolvable Repos table) to whatever we would like to call that stable branch (e.g., stable).

Hence, this branch information isn't part of the message but rather a parameter known (and effectively hard-coded) by the implementation (taken from this table in the did method spec).

i.e., this isn't about versioning the protocols or resolution but rather baking in a stable release process to the document storage & resolution source.

[swcurran]

So all DIDDocs in the repo would be found on that branch. That makes sense.

Thanks.

On Fri, Aug 2, 2019, 12:29 PM Troy Ronda notifications@github.com wrote:

@swcurran https://github.com/swcurran My above stability suggestion is to consider introducing a stable branch in the repo -- to allow for better release controls for these resolvable documents. This changes the cell that contains "master" (in Resolvable Repos table) to whatever we would like to call that stable branch. Hence, this branch information isn't part of the message but rather a parameter known by the implementation (taken from this table in the did method spec).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/129?email_source=notifications&email_token=AAHYRQVUS74GW4AJPLJXWIDQCSDKXA5CNFSM4IERLX72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OURAA#issuecomment-517818496, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHYRQTPZUIGUVY3QV3GZKLQCSDKXANCNFSM4IERLX7Q .

[dhh1128]

Okay, I see that we are bringing very different perspectives to the discovery issue. Below, I'm going to assume everyone is thoroughly familiar with this doc; if I say something that sounds odd, please refer there for background.

It's not the job of a DID value to facilitate discovery of protocol documentation; it's the job of an arbitrary URI of a type we don't constrain. The MTURI in the @type attribute of a DIDComm message doesn't have to begin with a DID. It might, or it might not. We've carefully written the protocol spec to allow either case. Both of the following are valid MTURIs:

did:abc:xyz?service=foo;protocolname/1.0/mymessagetype https://acme.com/protocols?protocolname/1.0/mymessagetype

I think this means that actual DID values here don't provide namespacing in the way Stephen was hoping. There's no intention that you should be able to reason about what the protocol RFC calls doc-uri (the URI where documentation about the protocol is hosted) in any way that peers inside it to find DID values. It's the full doc-uri component of MTURI, not just a DID portion inside it that may or may not exist, that namespaces the protocol name.

Discovery is explicitly described in the document I linked above:

The doc-uri portion is any URI that exposes documentation about protocols. A developer should be able to browse to that URI and use human intelligence to look up the named and versioned protocol. Optionally and preferably, the full URI may produce a page of documentation about the specific message type, with no human mediation involved.

If the doc-uri portion of MTURI is a DID URI (different from a DID value), then standard DID URI handling kicks in--just like if it is http-based, standard HTTP handling kicks in. A DID URI is going to have to be a service endpoint reference. That's turned into HTTP or another familiar protocol by resolving the DID, learning what the endpoint URI for that service is, and browsing that endpoint where the documentation is published. The method I wrote would make it easy for our community to do that; we just check in a DID doc that gives a service endpoint where protocol docs can be browsed, such as https://github.com/hyperledger/aries-rfcs/index.md. If BCGov wants to write some protocols outside the aries-rfcs repo, it would be easy to use the same mechanism. You'd have an MTURI that looks like this:

`did:aries:rfcs:1?service=bcdocs;magic/1.0/wave_wand`

...instead of an MTURI that looks like this:

`did:aries:rfcs:1?service=docs;magic/1.0/wave_wand`

Yes, you could change the DID value instead. But we don't require that anywhere, and we can't assume it. See my point? It's the full URI up to the semicolon that provides the basis of the namespace--not a DID value.

Stepping way back up the stack, we are solving two problems by walking away from the did:sov DID URI that we're currently using:

1. Sovrin's support for DID docs is still a bit limited (a single service endpoint), and it constrains people who work with it to use the Ed25519 curve. These are technical reasons why using a different kind of DID would be more optimal.

2. For political reasons, it would be good for Aries not to be opinionated about which DID methods it endorses (except maybe did:peer).

Because of both issues, moving to an Etherereum/Bitcoin/Veres One method didn't make sense either. This leaves us with moving to did:peer or did:git, or writing a new method. We decided that did:peer is for pairwise, not anywise, so that's out. We decided did:git is solving a different problem. So:

We are writing a new DID method where the use case is establishing an easy-to-manage, public identity for the community behind a repo.

We'll use it to create one or more DIDs that we can use inside MTURIs. But the DID values themselves only have a very indirect relationship with discovery. That's never been a central issue for this ticket.

[dhh1128]

One other comment after my long epistle: fully automated protocol discovery has never been a goal. The thing we're trying to discover is documentation. That has to be consumed by humans, not computers. Therefore, the bar for discoverability here is just "a human can find it easily" -- not "there must be a perfect algorithm that a computer can follow to suck down all the artifacts they need to consume in order to implement a protocol".

In choosing this position, we are in good company. This is exactly how XML namespaces work. The RFCs that define the namespacing mechanism say that if you follow the URI for the namespace, you get something helpful to a human. And if you've ever tried to browse one of those namespaces on the w3c's websites, you'll find that sometimes there are redirects, tables of contents you need to traverse, and so forth.

[troyronda]

From my point of view, The Aries DID method spec that @dhh1128 kindly wrote up is accomplishing today's key problems, matches up well with the community process, and the implementation is straightforward.

The READ operation boils down to FETCH document \<filename>.diddoc from path X from branch Y of repo Z; and X, Y, Z is a simple lookup from a mnemonic table based on the DID ID prefix. Descriptions for FETCH are provided for both a cloned git repo and GitHub URIs. The additional layer of a mnemonic table provides us the possibility of adding more resolvable repos in the future (without breaking existing DIDs). Simple enough.

Perhaps some background (similar to what was just described in the above @dhh1128 comments) could be added on how the Aries community, as the initial/primary user, will make use of the spec could help general understanding.

Anyways, I like it.

[talltree]

I only just caught up with this thread—it took me 30 mins of reading the messages in the thread, and then reading @dhh1128 's spec, and then re-reading the thread to understand why the did:git: method wasn't the right fit.

However, having been part of the group discussing did:git: at the last IIW, I'm not convinced that did:git: isn't what you want. As I understand it, did:git: automatically creates a DID for a new repo either as soon as the repo is created (if it's did:git: enabled from the start), or as soon as the developers did:git: enable it. So in theory the did:git: method could be used to identify not just that repo, but anything within that repo, i.e., any file, not just contributors who have their own DID doc there.

In fact I suspect that if we open a dialog with Dave Huseby and the did:git: folks, they would love the idea of using did:git: to be able to add persistent, resolvable, verifiable identifiers to anything in any git repo anywhere.

Now, the one thing you would not get is human-friendly names. did:git: identifiers are hashes. That's how it's decentralized. So that takes us to the question of how to layer human-friendly semantic names over un-friendly did:git: hashes.

On that, I would strongly advise not to try to do that with DID namespaces—I know of no way to do that that is not centralized, and DIDs were explicitly not designed to do semantic naming. The whole idea is to layer semantic names over the DID layer.

Thankfully, the good folks in BC Gov (led by @jljordan42 and @swcurran) have shown us a great way to do that using verifiable credentials no less (dogfooding!) Credential registries do a wonderful job of solving both the semantic naming and the human discovery problem. A credential registry like VON's OrgBook is searchable by all the attributes and metadata in the verifiable credentials submitted to it. And any organization wanting to promote its specs—such as the Linux Foundation—could easily run a credential registry for all the specs at the LF.

The only thing that would not provide is a human-friendly name for the entire DID used to identify an Aries message. But I would contend it's impossible to have that and still be decentralized (Zooko's Triangle et al), and given the choice, I'd vote for decentralized. Especially because the alignment with did:git: is so high.

[troyronda]

There are a several ways to increase the level of trust (and "decentralization") with varying complexity. If you skip to the bottom of this long comment, you can see a possible iterative approach.

Some approaches to increasing trust

• The maintainers could distribute the latest hash considered trusted (Trust up to this point in the repo). This method becomes increasingly annoying as the frequency of updates increases.
  • Of course, you could sign the hash and distribute key references instead...
• In the style of did:git, use an authentication block in did/repo.did that lists the keys that should be used to sign did change commits in the repo. Distribute the commit hash that contains this file and validate commit signatures going forward (Trust from this point in the repo).
• In the style of did:peer (& Sidetree), create a genesis version of each document and apply delta updates/patches based on the rules in the prior version. Distribute the genesis hash of each document (Trust from this point in the document history).

Note: These approaches are effectively increasing trust of the update history. (and hence, decreasing reliance on a canonical URL and GitHub controls).

Aliases

You can create human friendly aliases to hashes in the DID method spec, itself. Hence, we can avoid the complexity of a separate credential registry by embedding a registry into the spec (as we would expect a low number of aliases). As a concrete example, the registry could be the "Resolvable Repos" table plus an alias column (see below).

The acceptance of this alias (and the accompanying hash) as being the truth increases as the number of publications increases (e.g., canonical community pages, implementations, spec mirrors, etc).

A concrete example

If we used a did:git style authentication block:

• We would add another column to the "Resolvable Repos" table that lists the "genesis" commit hash of the repo.
• Create rules about validating each did-related commit (in sequence from the "genesis" commit hash) against the authentication block. Consider using a dedicated repo to reduce the commit count.
• Annotate or remove the GitHub Web URL READ capability from the did:aries spec (as it is less trusted). i.e., To achieve fuller trust, you need to clone the repo and validate the commit chain.

Easy to manage vs level of decentralization

@dhh1128 has many nuggets of wisdom in this thread. In particular on this topic:

use case is establishing an easy-to-manage, public identity for the community behind a repo.

I would say that the amount of decentralization we need should match the amount of decentralization in the community that the DIDs represent. That doesn't have to be global, ultra decentralization, because this isn't a general-purpose DID. But it should at least match the idea of repo maintainers and community calls jointly managing the evolution of state in a repo.

Iterative Approach

By using aliases in the spec (in the above example: "genesis" commit hash), the DID string does not actually change between a simpler method and a more souped-up version. i.e., It is still did:aries:rfcs.1.

The implication is that we can potentially start with a simpler mechanism (similar to @dhh1128 spec writeup) and upgrade the trust/decentralization characteristics over time, once needed.

(note: and the simplest "iteration 0" is doing string replacement of did:sov:BzCbsNYhMrjHiqZDTUASHg to did:aries:rfcs.1.)

[llorllale]

@talltree

One of the main pressing points re: this change is the need to move fast - the sooner we change the DID string on all messages the better. The alias idea at least gives us a starting point from which we can evolve all details at a later date.

We need an RFC anyhow. The RFC can define both the aries alias and the repo's canonical URL, quite similar to @dhh1128 's mnemonic table. Whether we end up using did:git under the hood or something else entirely different - that can be decided later.

[dhh1128]

@talltree: Part of your comment makes good sense to me, and I will go look more carefully at did:git. However, I'm going to vote to raise an RFC from the hackmd draft for the time being; I think @troyronda 's idea allows us to transition if we need to.

[talltree]

(Sorry to be slow; traveling).

If the idea is to solve the human-friendly naming problem by having a DID method spec that itself serves as a well-known registry of human-friendly DIDs used exclusively for specs, I get it. I could see making it "decentralized" simply by having that DID method spec define that multiple copies of the spec are maintained manually by trusted human "stewards" across voluntarily participating open source orgs (e.g., Hyperledger). If SDOs (standards development orgs) also wanted to be part of it, they could become "nodes" too.

In that is the case, may I suggest defining a richer namespace for this?

did:spec:hyperledger:aries:rfcs:1

So the DID method would be did:spec: and the namespace-specific-string (subnamespace) would be organized hierarchically as:

1. Governing authority
2. Project
3. Spec type
4. Spec ID

If that works, all we would need to do is update Daniel's proposed did:aries: method to become did:spec: and register hyperledger:aries:rfcs: as the first subspace.

I would be willing to help Daniel (and anyone else interested) as a co-author of this DID method spec (just keep in mind that I'll be on vacation for 2 weeks starting the end of this week).

Thoughts?