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 ***@***.***> 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 <#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 ***@***.***> 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 <#115 (comment)> mitigate the perception & did document maintenance issues). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#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 ***@***.***> 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: { ***@***.***": "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 <#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

[dhh1128]

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 ***@***.***> 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 <#129?email_source=notifications&email_token=AAQ3JCEEH6FGIYIHYEXCVALQH7GKBA5CNFSM4IERLX72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD535RKA#issuecomment-527947944>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQ3JCEFJ4ROS2LLFSZBL5LQH7GKBANCNFSM4IERLX7Q> .

[OR13]

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.

[troyronda]

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

[OR13]

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

[troyronda]

@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 the correct way to accomplish the following: https://aries.hyperledger.org/rfcs/1.diddoc;service=spec/didexchange/1.0/invitation

E.g., am I allowed to add an HTTP fragment?
https://aries.hyperledger.org/rfcs/1.diddoc#;service=spec/didexchange/1.0/invitation

Other examples of possible semantics are listed in the last bullet point under did:aries.

[OR13]

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.

[OR13]

We could start with https://aries.hyperledger.org/rfcs/didexchange/1.0/invitation

and then later once, we understand how to use matrix parameters...

transparently, and with no loss of functionality:

did:aries:rfcs.1;service=spec/didexchange/1.0/invitation

Which would in turn, resolve to:

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

As noted on the call.

[SmithSamuelM]

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
. Using a public key in the name string of the DID ensures that the DID is a UUID that can only be controlled by the holder fo the private key. Having some other basis for control induces name squatting. I think this is a dangerous precedent.

[SmithSamuelM]

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. A resolver can establish control of a DID and the initial DID Document creation by challenging the creator to auth with the private key. If we allow DIDs without a public key fingerprint in the DID then its a race to be the first to create a DID and DID document and without a control name spacing authority DID resolvers are left hanging. Its a race condition. I thought that including a public key fingerprint in the DID name string was a fundamental assumption of DIDs. Maybe it needs to be reinforced for this reason.

[OR13]

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.

[dhh1128]

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:

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

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

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

[dhh1128]

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

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

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

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

4. SHOULD be easy to implement, today, with existing tooling.

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

• use of DIDs: I told @talltree the other day that I had a hard time building a DIDComm infrastructure that didn't use DIDs soup to nuts. But I'm now reconsidering that, because I'm realizing that the specific operation we're trying to facilitate with this URI is browsing web content, not something more formal. Given that, maybe it's time to admit that DIDs as facilitators of fuzzy human content browsing is not a vital goal. Web browsing already works over https. It's not super trustworthy, but see my previous two points about high trust being a non-requirement.

[dhh1128]

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

[OR13]

context does more than namespace terms in a JSON document, it provides a way to look up a human readable description of the terms... 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:

w3c-ccg/did-spec#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

[ghost]

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:

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

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

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

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

[OR13]

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.

Such machine readable specs can be signed with JOSE or JSON-LD and hosted anywhere with tamper resistance.

Using https://github.com/decentralized-identity/well-known/tree/master/did-configuration

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

[dhh1128]

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

[troyronda]

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.

BTW - I think the point @OR13 makes is very good:

https can be used as the type string (good for human readable, retrieval and is associated to the Hyperledger Aries community), along with signed spec documents and a potential did-based linking (for machine readable).

[troyronda]

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 both hard-code the hash and implement the verification rules, of course. (previously mentioned in the alias comment above).

[ghost]

@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.
(Sorry for the multiple edits, I can't seem to make the 'V' icon go a way.)

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

:-)

[troyronda]

@dhh1128

Here are my proposed criteria

Intuitively, the URI defined by the Aries project MUST be under the care of Hyperledger. (e.g., using https implies a hyperledger.org domain.) Of course, messages MUST be able to have "3rd party" URIs for DIDComm protocols defined outside Aries.

I also think the idea of separating the string type from the machine readable integrity checks is a good idea. Having the type string as https does not prevent future RFC efforts from defining a machine parsing strategy that has additional integrity protections. E.g., see @OR13 comments above.

Concretely:

• Now: update RFCs with an https type string using a domain under hyperledger.org (i.e., the https option)
  • easy to understand for spec readers and easy to browse to documentation.
  • semantically attached to Hyperledger Aries in the string itself (rather than a layer of indirection that is caused by DIDs).
• Future: Separate RFC that defines machine parseable format and algorithm:
  • define the machine parseable format.
  • mechanism to retrieve the machine parseable format based on the https type string.
  • mechanism for the Hyperledger community to declare signing DIDs.
  • specification of how to check the integrity of the documents.
    • integrity linked to the signing DIDs.

This complies with the criteria laid out by @dhh1128 above. The future RFC thought is for point 3 related to SHOULD allow for automated processing of spec-related data.

[troyronda]

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