search

hyperledger / aries-rfcs

Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions
https://hyperledger.github.io/aries-rfcs/
Apache License 2.0
326 stars 217 forks source link

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

Closed troyronda closed 5 years ago

troyronda commented 5 years ago

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.

dhh1128 commented 5 years ago

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.

talltree commented 5 years ago

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

talltree commented 5 years ago

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

OR13 commented 5 years ago

https://github.com/decentralized-identity/github-did

If this is useful.

I should mention that originally this project was focused on trying to do more what did:git is doing, but because thats a lot harder, and because BTCR and others often use https uri's for continuation, we built this method to test cryptography without coupling to a specific ledger.

Because github is very easy to update, its simple to add experimental crypto, for testing purposes.

I've been looking for collaborators, and am happy to make changes to this method that might be useful for your purposes here.

did:github:OR13 is me, the method is not registered yet, but I have started the conversation with GitHub about getting that done.

peacekeeper commented 5 years ago

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 ?

dhh1128 commented 5 years ago

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

kdenhartog commented 5 years ago

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 ":"<emoji name>":" 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.

peacekeeper commented 5 years ago

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:

kdenhartog commented 5 years ago

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

troyronda commented 5 years ago

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

HTTPs URI Examples:

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:

But for the https option, I would suggest a hyperledger.org based domain seems better than a GitHub domain anyways.

dhh1128 commented 5 years ago

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 notifications@github.com 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:

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:

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 .

OR13 commented 5 years ago

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 commented 5 years ago

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

OR13 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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:

dhh1128 commented 5 years ago

@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 commented 5 years ago

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:

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

ghost commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

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 commented 5 years ago

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