Should the Aries Community DID be under did:peer (rather than did:sov)?

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.

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

@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.

@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.

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

@dhh1128 Agree that did:git for a git-oriented community has a nice semantic feeling to it.

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?

@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?

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

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<EMAIL_ADDRESS>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
.

@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).

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<EMAIL_ADDRESS>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
.

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?

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:

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.

Any such files create dids.

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.

Updates and deletes are just commits to the individual docs.

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<EMAIL_ADDRESS>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
.

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

@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.

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.

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

@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:

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.

Any such files create dids.

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.

Updates and deletes are just commits to the individual docs.

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.

@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.

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).

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).

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.

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?

@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.

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.

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

@dhh1128 Suggest clarifying that the type of the repo is git.

@dhh1128 Another consideration for the implementor related to the release process. (Should we use the master branch; should we use the latest tag or specified tag or HEAD).

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

branch and versioning to enable release processes (see next 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!

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.)

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:

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.

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.

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

@dhh1128 LGTM. Thanks for incorporating the suggestions.
I think it would be great to use the DID spec's versioning semantics. (I'm not familiar with the details.)
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 mitigated by sufficient CI testing... But it might be an idea to have a stable branch for the did docs that is mutated less frequently than master.

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 this. Is it about namespace and specification discovery?

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. Namespacing is just one of many uses for identity.
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?

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.

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 prefix gives us more future-proofing and flexibility.

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

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)

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.

@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).

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<EMAIL_ADDRESS>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
.

Okay, I see that we are bringing very different perspectives to the discovery issue. I'm going to assume everyone is thoroughly familiar with this doc below; if I say something that sounds odd, please refer there for background.
It's not the job of a DID value to facilitate discovery; 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 kind of 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:bcgov:1?service=docs;magic/1.0/wave_wand`

...instead of an MTURI that looks like this:
`did:aries:rfcs:1?service=docs:magic/1.0/wave_wand`

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:

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.

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.

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 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.

From my point of view, the did:aries 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 .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 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.

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.

@talltree  There are a several ways to increase the level of decentralization with varying complexity. I would argue that the goal should be "decentralized enough" for the point in time. Note: If you skip to the bottom of this long comment, you can see a possible iterative approach.
Decentralization

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).

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).
I would argue that decentralization increases as the number of publications of this hash/genesis hash/keys/aliases increases (e.g., 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.

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 complex) more decentralized version. i.e., It is still did:aries:rfcs.1.
The implication is that we can start with a simpler mechanism (similar to @dhh1128 spec writeup) and upgrade the decentralization characteristics over time.

@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.

@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.

(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:

Governing authority
Project
Spec type
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 keeping in mind that I'll be on vacation for 2 weeks starting the end of this week).
Thoughts?

Drummond: this is an interesting idea. I would like to discuss it with you when you're less constrained by travel.
Human-friendliness has not been a design goal thus far. (The reason I chose "1" as an example method-specific name is that there's no value in making it more complicated. But what was "1" in my example could just as easily be a big sequence of arbitrary characters.) Brevity is a minor goal, because this value will be embedded in every DIDComm message that's ever sent or parsed, including ones that have to render in QR codes. But even brevity is only a secondary concern.
When can we chat? As @llorllale has pointed out, we need to resolve this asap.

@dhh1128 I'm in Victoria with the BC Gov team today but could chat briefly this afternoon. I'll ping you offline to arrange a time.

Note: I talked to @dhh1128 about this today and agreed with him that did:repo: would be good. He's on it.

https://github.com/decentralized-identity/github-did
If this is useful.

I think my (heretical) opinion about this thread is why do we need DIDs here? Why not use
https://github.com/hyperledger/aries-rfcs/didexchange/1.0/invitation
instead of
did:repo:<something>/didexchange/1.0/invitation ?

Yes. I said that almost a year ago, when @talltree first asserted that we should use DIDs for the URN/URI we needed. I don't think I can articulate Drummond's reasoning like he can, so I will let him respond. (But expect a delay, as he is currently on vacation.)

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

This is becoming much more common on web apps as of recently (e.g. slack, rocketchat, and github I've seen it now) and may be something we need to consider.
What's happening is that they're parsing ":"":" to be automatically converted to an emoji. If there's a name collision occurs with parts of the URI in the DID (given we use :) parsers may automatically convert this to an emoji which are different unicode characters. I'm not too concerned with the risk to believe it should be avoided right now, but it's worth noting as a thing to monitor.

Maybe we should actually allow unicode characters in the DID method name syntax? After a few months the method registry would probably look really funny. Hmm no better not :open_mouth:

Just finally getting through to reading this thread. There's some excellent discussions here and a few paths that we can take. Most (if not all) do not produce contradicting requirements and shouldn't be a problem.
While @dhh1128 pointed out that machine readability is not a use case (now) I'd like to make it one in the future. This is going to be very useful to build a semantic data layer in the future, but is not something we need to be building in now. I think this leads to the ability to build a package manager based on DIDs so that an agent can automatically download message handler code if the DID is listed in a sources.list like doc (coming from a apt-get background).
Another aspect worth considering is that for our specific use case I think we really only need a single DID to represent the core libraries. If someone wishes to publish an extension protocol, it's not necessary (nor do I think suggested) that they use the community DID to publish the protocol under. Rather, I think it makes more sense that they publish it to this repository if they choose and set the endpoint in the DID Doc to this repo just like they would the community DID. This allows protocol developers to select any DID that they wish to establish a DID.
Here's the most contentious part of my mental model. A protocol can only be moved under the community DID namespace once it's hit Active status - not Accepted. This is for two reasons. It makes this issue a non blocker for the most part. Two, it means that Accepted status carries less weight which I believe is going to be an advantage when we have a larger group of competing opinions (such as if DIF community decide to move forward with this work.)

@dhh1128 I'm curious if there has been any updates for this topic. I think we left off at three main options:

Create an Aries DID method.
Use the GitHub DID method.
Use https for the URI rather than a DID method.

HTTPs URI Examples:

https://aries.hyperledger.org/didexchange/1.0/invitation
https://aries.hyperledger.org/rfcs/didexchange/1.0/invitation
https://aries.hyperledger.org//didexchange/1.0/invitation
https://aries-rfcs.hyperledger.org/didexchange/1.0/invitation
https://aries-.hyperledger.org/didexchange/1.0/invitation

Note https://github.com/hyperledger/aries-rfcs/didexchange/1.0/invitation would not be resolvable without special client handling. The directly resolvable versions using a GitHub domain would be something like:

https://raw.githubusercontent.com/hyperledger/aries-rfcs/master//didexchange/1.0/invitation
https://aries-rfcs.github.io//didexchange/1.0/invitation (via GitHub pages)

But I would suggest a hyperledger.org based domain would be better anyways.

Tagging @talltree, as I talked to him about this and he promised to weigh
in.
On Wed, Sep 4, 2019 at 5:15 PM Troy Ronda<EMAIL_ADDRESS>wrote:

@dhh1128 https://github.com/dhh1128 I'm curious if there has been any
updates for this topic. I think we left off at three main options:

Create an Aries DID method.
Use the GitHub DID method.
Use https for the URI rather than a DID method.

HTTPs URI Examples:

https://aries.hyperledger.org/didexchange/1.0/invitation
https://aries.hyperledger.org/rfcs/didexchange/1.0/invitation
https://aries.hyperledger.org//didexchange/1.0/invitation
https://aries-rfcs.hyperledger.org/didexchange/1.0/invitation
https://aries-.hyperledger.org/didexchange/1.0/invitation

Note https://github.com/hyperledger/aries-rfcs/didexchange/1.0/invitation
would not be resolvable without special client handling. The directly
resolvable versions using a GitHub domain would be something like:

https://raw.githubusercontent.com/hyperledger/aries-rfcs/master/
/didexchange/1.0/invitation
https://aries-rfcs.github.io//didexchange/1.0/invitation (via GitHub
pages)

But I would suggest a hyperledger.org based domain would be better
anyways.
—
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=AAQ3JCEEH6FGIYIHYEXCVALQH7GKBA5CNFSM4IERLX72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD535RKA#issuecomment-527947944,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQ3JCEFJ4ROS2LLFSZBL5LQH7GKBANCNFSM4IERLX7Q
.

For managing a single source of truth about a spec version, I think its best to just use HTTPS. The hosting does not matter, but there are a lot of usability benefits for just being able to open a link.
I agree that a hyperledger.org name would be best, nothing to stop you from using github behind it.

This topic is being discussed on today's Aries WG call.
Here is my attempt at a comparison of the proposed methods. Please do chime in :).

https

Example: https://aries.hyperledger.org/rfcs/didexchange/1.0/invitation
Simplest
Most human friendly (using https is well known)
Machine friendly (it's https)
Provides context in the URI string (hyperledger.org and aries)
Does not require a particular ledger backend (i.e., ledger neutral)
Decoupled from hosting (e.g., GitHub)
Easy to maintain DID documents (push update to website based on commits to GitHub)
Needs some extra specification to add DID document semantics

So that you get something like: GET https://aries.hyperledger.org/rfcs/1.diddoc with ;service=spec/didexchange/1.0/invitation

did:aries

Example: did:aries:rfcs.1;service=spec/didexchange/1.0/invitation
Simple (in some ways, this option acts as a did method alias for https).
Provides DID semantics on top of the https alias.
Human & machine friendly (but a bit less than https since there is a level of indirection)
Provides context in the URI string (aries)
Does not require a particular ledger backend (i.e., ledger neutral)
Decoupled from hosting (e.g., GitHub)
Easy to maintain DID documents
The DID method spec could be augmented over time (e.g., as RFCs)

Could potentially include hash information about the DID documents (or as hashlinks); or
Additional DID document proof requirements; or
Some semantics from did:github

did:github

Example: did:github:hyperledger;service=spec/didexchange/1.0/invitation
Simple (in some ways, this option acts as a did method alias for GitHub https access)
Provides DID semantics on top of the https alias.
Human & machine friendly (but a bit less than https since there is a level of indirection)
Provides context in the URI string (hyperledger)

Note: we may want to request modification to be more specific to aries

Does not require a particular ledger backend (i.e., ledger neutral)
Coupled to hosting (i.e., GitHub)
Easy-ish to maintain DID documents (push updates to GitHub)

Note: did:github currently uses linked data signatures

I recently built this: https://context.transmute.org/
For testing / documenting extensions to JSON-LD, if you opt to go the HTTPs route, this might be a useful reference since it provides an example of hosting machine and human readable spec on github with a proper domain.
I don't follow:
Needs some extra specification to add DID document semantics
So that you get something like: GET https://aries.hyperledger.org/rfcs/1.diddoc with ;service=spec/didexchange/1.0/invitation

This seems to be mixing DID Fragments with URLs... I recommend not doing that, but if it must be done, i think it can be accomplished with: https://help.github.com/en/articles/redirects-on-github-pages

@OR13 I should have said "Presumably needs some extra specification" :). Would you be able to provide an example of using DID documents semantics using an https URL?
More specifically, I wasn't sure if this was legal (and if not, what is the corrected version?): https://aries.hyperledger.org/rfcs/1.diddoc;service=spec/didexchange/1.0/invitation

You would not want to use a URL fragment, because of things like: https://stackoverflow.com/questions/2286402/url-fragment-and-302-redirects
The fragment is supposed to get reattached... you can see why that is problematic here:
https://w3id.org/security#publicKeyPem
IMO its better to avoid redirects and just use proper versioned flat directory structure. It makes it much easier to update documentation and machine related data in one place.

To clarify my confusion because the did does not include a public key fingerprint who "controls" the did document as anyone can create a did with this namespace.
It seems that the did must include the GitHub hash of the commit or something to ensure unique ownership
, otherwise we have name squatting not on the method but on the DID itself
. Or is it that the Aries community under Hyperledger governance is the owner and we are setting a precedent for name squatting on human friendly did namespaces

Some part of the DID needs to include a public key fingerprint. This prevents name squatting because only the holder of the associated private key can prove control over the DID. The DID method via its authentication policy can enforce this requirement over the DID document. The DID method needs to define which part of the DID contains the public key fingerprint. This is an essential part of self-certifying identifiers. The "Certificate Authority" is the holder of the associated private key. As soon as we divorce the PKI key pair from the DID itself we open up name squatting.  This may be an issue for the DID spec. I believe it was always implied that some portion of the name string be a public key or fingerprint of a public key but it appears that by this proposal and the ensuing discussion that we have lost something really really important. That is decentralized proof of control of the identifier.

I think the strongest and most generous argument for using a did method to serve human and machine readable documentation is that it gives the controller of a DID the ability define which namespaces it wants to allow (by adding them to services).
This is different than extending the "@context": ["https://w3id.org/did/v1"],, which a controller may or may not be allowed to do depending on the DID Method.
We have to assume that if did:aries is created, we will see did:sidetree, did:facebook, etc... we already have did:github...., but we will also see:
did:github:OR13;service=spec/didexchange/1.0/invitation
did:github:aries;service=spec/didexchange/1.0/invitation
did:sov:BzCbsNYhMrjHiqZDTUASHg;service=spec/didexchange/1.0/invitation
did:sov:BzCbsNYhMrjHiqZDTUASHg;service=aries/didexchange/1.0/invitation
did:secure:aries;service=spec/didexchange/1.0/invitation
With services like:
"service": [{
    "id": "did:sov:BzCbsNYhMrjHiqZDTUASHg#aries",
    "name": "spec",
    "type": "AriesProtocolVersion1.0Service",
    "serviceEndpoint": "https://evil.aries.example.com/"
  }...

This service would serve different documentation than did:aries:rfcs.1;service=spec/didexchange/1.0/invitation...
Its not a security issue, since all agent implementations will probably hard code the spec versions they want, and it would take a PR review to get my evil did spec name space merged, but the point is that service is under the control of the DID controller.
Altering the context in which a DID Document is interpreted is a dangerous thing to allow, and we are all already vulnerable to abuse by the domain controllers of  "@context": "https://w3id.org/did/v0.11",(pulled from "did:sov:WRfXPg8dantKVubE3HX8pw")....
Admins of w3id.org can break JSON-LD Signatures over did:sov:WRfXPg8dantKVubE3HX8pw....
If we go the route of using did based spec name spaces, and we use them for signing, we will need to worry about the same kind of attacks here as well.
I'm in favor of not adding another standard if we can't articulate why the existing standards we rely on today are not a solution. You can implement a custom JSON-LD Context loader, and have it use a DID resolver to solve this problem, here is the code to do that:
https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js/blob/master/packages/lds-ecdsa-secp256k1-2019/src/defaultDocumentLoader.ts#L18
Regarding key material, its unfortunately not a requirement for creating a valid DID according to the spec:
https://w3c-ccg.github.io/did-spec/#binding-of-identity
Proving control of a DID, i.e., the binding between the DID and the DID Document that describes it, requires a two step process:

Resolving the DID to a DID Document according to its DID method specification.
Verifying that the id property of the resulting DID Document matches the DID that was resolved.
It should be noted that this process proves control of a DID and DID Document regardless of whether the DID Document is signed.

This gives method implementers complete control over "how centralized" a method is, and resulted in the rubric debate.
Using a DID as a way to point to a spec is achievable, and in the interest of being the first and trying to control the abuse that will come from the associated method squatting, it might still be a good call.
The reasons NOT to use a did method for versioning human and machine readable specs are:

We already use JSON-LD, it solves this problem, adding another alternative increases complexity, creates confusion over how to represent your spec extension, and increases attack surface.
Humans will probably use a web browser to read the documentation 99% of the time, including if they were to use the matrix parameters to resolve the documentation from a DID.

I'm in favor of starting with HTTPs and maybe transitioning to DID method based stuff later... When some machine and human readable feature is discovered that is not solved by JSON-LD.

After our call today, I spent some time thinking about this. I also chatted with @SmithSamuelM and @troyronda . Here is a specific proposal about next steps:

We need a deadline for attempting to decide, so we create moderate pressure to force the issue to closure. I suggest we choose the Wed afternoon Aries meeting in 1 week (Sep 18, 2019).

We need a method for deciding. I suggest we hold an up-or-down vote on a written proposal, where abstention is treated as the absence of dissent, and where it takes >50% dissent to kill the proposal. This means the proposal is moderately likely to pass, unless there is strong and articulate opposition.

We need criteria for deciding. I think this should be articulated as a series of requirements. I'll propose some in my next comment.

Do these feel like acceptable next steps to everyone?

Here are my proposed criteria (the requirements that I think our solution must satisfy), in descending order of importance:

MUST be politically neutral with respect to various constituencies that might approach Aries RFCs. (This is the main reason why did:sov was not acceptable.)

MUST provide reasonable human browsability/discoverability of spec docs, using either an MTURI or a PIURI as a starting point. A human who sees a DIDComm message should be able to find the spec where that message and its associated protocol are defined, with minimal coaching, tooling, or effort.

SHOULD be possible to define a convention (or use an existing convention) that allows the fetching and processing of spec-related data/metadata by fully automated processes, using the MTURI or PIURI as input.

Would be nice if the resulting URIs were short, all else being equal.

Things that I claim are NOT requirements include:

Tamper-prevention/evidence (cryptographic integrity): Even if we used a very carefully built mechanism that involved DID resolution, with DIDs that cannot be squatted and keys that are cryptographically strong, the result will be a service endpoint that's almost certainly https, and human browsing of https is unlikely to result in high trust no matter what we do. It IS theoretically possible to construct a mechanism where the DID resolution is very secure, and the endpoint uses hashlinking to provide tamper evidence, but I think the juice is not worth the squeeze, because it would only provide value when the mechanism is fully automated, not when it is used manually by humans. And I don't think cryptographic guarantees are an appropriate goal anyway. Automated processing shouldn't ever go as far as installing a handler for a protocol without consulting the humans who are supposed to be the last word in whether the trust of the system actually meets their needs.

code signing and other identity operations: I don't think this identifier/browse-uri for specs shouldn't be conflated with a community wanting to sign things in an official way. That introduces unnecessarily difficult requirements at present.

@OR13 It sounds like you and I are headed in the same direction; I am now beginning to intuit that https represents the best combination of tradeoffs. However, I don't feel I understand the meaning of the phrase "this problem" in your claim that JSON-LD already solves "this problem". @context in jsonld lets you namespace what it calls "terms" (JSON keys), and Aries is intentionally compatible with that usage. Is internal namespacing in a message the problem you're referring to?

context does more than name space terms in a JSON document, it provides a way to look up a human readable description of the keys... for example:
https://github.com/web-payments/web-payments.org/blob/master/contexts/security-v1.jsonld#L41
Is defined by:
https://github.com/web-payments/web-payments.org/blob/master/contexts/security-v1.jsonld#L7
Which get converted to:
https://w3id.org/security#publicKeyPem
Which gets redirected to:
https://web-payments.org/vocabs/security#publicKeyPem
What this means is that the way a JSON-LD Signature is formed is actually tied to how contexts are defined, and changing the context (by controlling the domain) allows you to alter how a signature would be verified...
If you are scratching your head about that... so I am I, i just recently realized this, while trying to add support for community public key types:
https://github.com/w3c-ccg/did-spec/pull/270
As manu notes on the PR, one solution is to host your own context, and documentation. That way you can ensure that:
"publicKeyJwk": "sec:publicKeyJwk",

Does not leave a user sad and confused when they try and read the docs about it on:
https://w3id.org/security#publicKeyJwk
Here is a repo with some example and tests to demonstrate this further:
https://github.com/transmute-industries/context

After today's discussion, I reviewed the original proposal (RFC #115), which described using "predefined identities" as public DIDs (without the ledger) and example / fake DIDs for referencing sample data.  With that I had a few of questions:

Tamper-evidence is a main motivation for using DIDs, Sovrin, Hyperledger, etc.  Why would this not be a requirement?

Rather than 'enhance' DIDs to work like URLs wouldn't it be simpler to stay with URLs (https) when warrented?

"Politically Neutral" -- I'm not sure what this means.  Don't DIDs reference whichever ledger they are published to?   If so, then it should't matter that trust for a particular component is anchored in whichever ledger the author chose.

Are we skipping the ledger?  On the proposal page, it says 2 things:
a) "The collective Aries developer community is represented by: [DID & verkey removed].  This DID is currently allocated, but not actually registered on Sovrin's mainnet."
b) Subgroups:  "The Aries community may create subgroups with their own DIDs. If so, we may publish such information here."

I'm confused as to why the Hyperledger Aries DID would not be published to a ledger.  It seems like there is more trust using the ledger than by publishing it on a github page where an adversary could change it.
Regarding trust, if a DID points to the ledger, then agents can retrieve the public key to verify the doc it immutably references.  However, if the did method points to a web page first, then agents will first retrieve the doc and then look for a public key to match its signature / fingerprint.  With the latter, it seems like an adversary could substitute a doc containing a valid signature using their own key.
Am I missing a part of the proposal?

See also: https://github.com/snowplow/iglu/wiki/Self-describing-JSON-Schemas
Without knowing what format the machine readable spec would be in, I can only assume some combination of JSON-LD / JSON-Schema.

@smccown

Tamper-evidence is a main motivation for using DIDs, Sovrin, Hyperledger, etc. Why would this not be a requirement?

We're talking about documentation here, not something highly precise. It should always be possible to change a comma or fix a typo in documentation without "breaking" the docs. We don't want the strong tamper-proof guarantee because it carries with it a fragility that's counterproductive.
Of course we still want tamper evidence for DIDComm messages themselves--just not for the documentation behind them.

"Politically Neutral" -- I'm not sure what this means. Don't DIDs reference whichever ledger they are published to? If so, then it should't matter that trust for a particular component is anchored in whichever ledger the author chose.

The use of specific ledgers is politically charged. We don't care about that for DIDs of individuals operating in the ecosystem--but we do care about it for the anchoring of specs. We don't want all our specs to be anchored to Sovrin or Ethereum or whatever. (I have numerous anecdotes that tell me this association between specs and a ledger carries more importance than it should, if humans were rational actors.)

I'm confused as to why the Hyperledger Aries DID would not be published to a ledger. It seems like there is more trust using the ledger than by publishing it on a github page where an adversary could change it.

An adversary can't change a published git commit. We were thinking that a git repo provided adequate tamper resistance. Effectively, git is a ledger.

Regarding trust, if a DID points to the ledger, then agents can retrieve the public key to verify the doc it immutably references. However, if the did method points to a web page first, then agents will first retrieve the doc and then look for a public key to match its signature / fingerprint. With the latter, it seems like an adversary could substitute a doc containing a valid signature using their own key.

With both the proposed "aries" did method and the github method, the resolution is tied to a repo, not necessarily to https. If you have the repo cloned locally, you can do resolution there. This would sidestep any hacks against the publicly hosted repo accessed by https.
However, you do have a point that because the DID value does not contain a commit hash or a public key (or some value derived from one of these), it would be possible for an attacker to play games with how the DID value is dereferenced if https is used.

They could be signed by did:sov, did:v1, did:ion, all linked to hyperledger.com.

or presumably did:git using a repo-id recognized by the implementations and where the underlying repo is hosted by Hyperledger.

However, you do have a point that because the DID value does not contain a commit hash or a public key (or some value derived from one of these), it would be possible for an attacker to play games with how the DID value is dereferenced if https is used.

Unless the did:aries method specifies the hash and implementations hard-code it, of course. (previously mentioned in the alias comment above).

@dhh1128

We're talking about documentation here, not something highly precise. It should always be possible to change a comma or fix a typo in documentation without "breaking" the docs. We don't want the strong tamper-proof guarantee because it carries with it a fragility that's counterproductive.

I very much understand the expediency of wanting to fix a typo without creating a bunch of work.  However, that is precisely why "https" should be used instead of a "did:" reference.  Presently, SSI, Hyperledger, DIDs, Sovrin, Evernym, etc. have a great reputation for providing very strong security / crypto.  If we create a situation where some DIDs are very secure, others are only kind of secure, and others are not very secure, and the user doesn't know the difference, then we've created trust uncertainty for users and special cases for agent apps to deal with.
Instead of using "did:ares:..." to reference documentation that doesn't need to be secure, I'd like to first advocate for "https".  However, if the community would like to use the Aries infrastructure for things that don't have to be as secure, then I'd proposed a different moniker, such as "simpleDID:aries:..." or something like that.  This makes the security level easily human-readable.

"Politically Neutral" ....

The use of specific ledgers is politically charged. ...

I don't doubt that.  :-)  However, can't we help the industry get over that?  For example, most don't care if a website's cert is from Let's Encrypt or DigiCert as long as they're secure.

An adversary can't change a published git commit. We were thinking that a git repo provided adequate tamper resistance. Effectively, git is a ledger.

Are you sure?  We can talk more in a side channel, but I've read of some methods to make commits backwards in git history, so I wouldn't dismiss the possibility.

Regarding trust, if a DID points to the ledger, then agents can retrieve the public key to verify the doc it immutably references. However, if the did method points to a web page first, then agents will first retrieve the doc and then look for a public key to match its signature / fingerprint. With the latter, it seems like an adversary could substitute a doc containing a valid signature using their own key.

With both the proposed "aries" did method and the github method, the resolution is tied to a repo, not necessarily to https. If you have the repo cloned locally, you can do resolution there. This would sidestep any hacks against the publicly hosted repo accessed by https.
However, you do have a point that because the DID value does not contain a commit hash or a public key (or some value derived from one of these), it would be possible for an attacker to play games with how the DID value is dereferenced if https is used.

:-)

During our Aries WG call (2019-09-18B), the consensus was to use https. This change will be tracked in #225.