Method 2

[TelegramSam]

This method adds a way to have a different authentication key than key agreement key. It adds a new method identifier (2) and explains how it works. Comments, Suggestions, Corrections, and Ideas welcome.

[dhh1128]

I am in favor of merging this change. I will let the PR sit for a week to see if community members have feedback.

[swcurran]

I believe the "PublickKey" array is not longer part of the did core spec. Need to decide where this goes in the new did core spec.

[TelegramSam]

I was basing this off the did:key spec, which has not been updated. We'll need to make sure we align with the core spec.

[kdenhartog]

Looks like this part is missing now, but for future reference publicKey has been deprecated in favor of verificationMethod

[dhh1128]

@llorllale has submitted pr #27 to update to verificationMethod. I'll try to merge both PRs together.

[llorllale]

did:key -> did:peer

[llorllale]

This PR is strangely focusing on signing and encryption keys instead of being generalized. Furthermore, reserving the first key for "encryption" keys does not seem compatible with the requirement that deltas need to be signed by the inception key.

The mechanism for determining the purpose of keys is under defined. How does this scheme codify P256 keys for use in key agreement instead of signatures?

There are other details missing here related to the algorithms, such as how to specify the exact key wrapping scheme and so forth.

This PR does not solve the problem we have in DIDComm v1 with naked keys.

[TelegramSam]

This PR does not solve the problem we have in DIDComm v1 with naked keys.

Suggestions on how to correct any unsolved issues are welcome.

[llorllale]

From today's Aries B call:

• the additional code is not certified by the corresponding key
• does not specify all JWE parameters
• how does this fit into the overall did:peer spec?
• does not specify service endpoints

[kdenhartog]

I think I found a way to abuse JSON-LD semantics such that you can produce a self certifying identifier that is based on the entire did document but isn't affected by the id property revolving door that's normally encountered.

The algorithm for this would be.

produce a DID Document that looks like the following:

{
  "@context": ["https://www.w3.org/ns/did/v1", {"id": null}],
    "authentication": [
      {
        "id": "#z6MkecaLyHuYWkayBDLw5ihndj3T1m6zKTGqau3A51G7RBf3",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "AKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf"
      }
    ],
    "capabilityInvocation": [
      {
        "id": "#z6MkhdmzFu659ZJ4XKj31vtEDmjvsi5yDZG5L7Caz63oP39k",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "4BWwfeqdp1obQptLLMvPNgBw48p7og1ie6Hf9p5nTpNN"
      }
    ],
    "capabilityDelegation": [
      {
        "id": "#z6Mkw94ByR26zMSkNdCUi6FNRsWnc2DFEeDXyBGJ5KTzSWyi",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "Hgo9PAmfeoxHG8Mn2XHXamxnnSwPpkyBHAMNF3VyXJCL"
      }
    ],
    "assertionMethod": [
      {
        "id":"#z6MkiukuAuQAE8ozxvmahnQGzApvtW7KT5XXKfojjwbdEomY",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "5TVraf9itbKXrRvt2DSS95Gw4vqU3CHAdetoufdcKazA"
      }
    ]
}

Pass this into an RDF Normalize function which will produce a set of N-Quads that match this

_:b0 <https://w3id.org/security#assertionMethod> _:b1 .
_:b0 <https://w3id.org/security#authenticationMethod> _:b2 .
_:b0 <https://w3id.org/security#capabilityDelegationMethod> _:b3 .
_:b0 <https://w3id.org/security#capabilityInvocationMethod> _:b4 .
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#Ed25519VerificationKey2018> .
_:b1 <https://w3id.org/security#publicKeyBase58> "5TVraf9itbKXrRvt2DSS95Gw4vqU3CHAdetoufdcKazA" .
_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#Ed25519VerificationKey2018> .
_:b2 <https://w3id.org/security#publicKeyBase58> "AKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf" .
_:b3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#Ed25519VerificationKey2018> .
_:b3 <https://w3id.org/security#publicKeyBase58> "Hgo9PAmfeoxHG8Mn2XHXamxnnSwPpkyBHAMNF3VyXJCL" .
_:b4 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#Ed25519VerificationKey2018> .
_:b4 <https://w3id.org/security#publicKeyBase58> "4BWwfeqdp1obQptLLMvPNgBw48p7og1ie6Hf9p5nTpNN" .

hash those N-Quads to the following hash a0acef8a8a4421b4b4f223adc1f170fcaacd2bbfb8937e3a74ff2d0331436705
(this is hex encoded, but the encoding could be changed/multibased)

post inject the id property and an @base property which contains the did like so (which doesn't change the N-Quads, and therefore doesn't break the self certification):

{
  "@context": ["https://www.w3.org/ns/did/v1", {"id": null, "@base": "did:example:a0acef8a8a4421b4b4f223adc1f170fcaacd2bbfb8937e3a74ff2d0331436705"}],
    "id": "did:example:a0acef8a8a4421b4b4f223adc1f170fcaacd2bbfb8937e3a74ff2d0331436705",
    "authentication": [
      {
        "id": "#z6MkecaLyHuYWkayBDLw5ihndj3T1m6zKTGqau3A51G7RBf3",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "AKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf"
      }
    ],
    "capabilityInvocation": [
      {
        "id": "#z6MkhdmzFu659ZJ4XKj31vtEDmjvsi5yDZG5L7Caz63oP39k",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "4BWwfeqdp1obQptLLMvPNgBw48p7og1ie6Hf9p5nTpNN"
      }
    ],
    "capabilityDelegation": [
      {
        "id": "#z6Mkw94ByR26zMSkNdCUi6FNRsWnc2DFEeDXyBGJ5KTzSWyi",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "Hgo9PAmfeoxHG8Mn2XHXamxnnSwPpkyBHAMNF3VyXJCL"
      }
    ],
    "assertionMethod": [
      {
        "id":"#z6MkiukuAuQAE8ozxvmahnQGzApvtW7KT5XXKfojjwbdEomY",
        "type": "Ed25519VerificationKey2018",
        "publicKeyBase58": "5TVraf9itbKXrRvt2DSS95Gw4vqU3CHAdetoufdcKazA"
      }
    ]
}

Now you should have a valid DID Document that is self certifying, but doesn't have massive dids and comes with the added bonus that you can reorder the did document without causing any sort of canonicalization issues (since N-Quads handle that canonicalization for you).

Then in order to pass this via a DIDUrl, we could combine it with the intial-state query parameter such that the entire thing could be sent and expandably resolvable, but still verifiable to be connected to the initial state. Even better, we can include any property we want in there (including extension properties we might want in the future)

did:example:a0acef8a8a4421b4b4f223adc1f170fcaacd2bbfb8937e3a74ff2d0331436705?initial-state=ewogICJAY29udGV4dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnL25zL2RpZC92MSIsIHsiaWQiOiBudWxsLCAiQGJhc2UiOiAiZGlkOmV4YW1wbGU6YTBhY2VmOGE4YTQ0MjFiNGI0ZjIyM2FkYzFmMTcwZmNhYWNkMmJiZmI4OTM3ZTNhNzRmZjJkMDMzMTQzNjcwNSJ9XSwKICAgICJpZCI6ICJkaWQ6ZXhhbXBsZTphMGFjZWY4YThhNDQyMWI0YjRmMjIzYWRjMWYxNzBmY2FhY2QyYmJmYjg5MzdlM2E3NGZmMmQwMzMxNDM2NzA1IiwKICAgICJhdXRoZW50aWNhdGlvbiI6IFsKICAgICAgewogICAgICAgICJpZCI6ICIjejZNa2VjYUx5SHVZV2theUJETHc1aWhuZGozVDFtNnpLVEdxYXUzQTUxRzdSQmYzIiwKICAgICAgICAidHlwZSI6ICJFZDI1NTE5VmVyaWZpY2F0aW9uS2V5MjAxOCIsCiAgICAgICAgInB1YmxpY0tleUJhc2U1OCI6ICJBS0pQM2Y3QkQ2VzRpV0VROWp3bmRWVENCcTh1YTJVdHQ4RUVqSjZWeHNmIgogICAgICB9CiAgICBdLAogICAgImNhcGFiaWxpdHlJbnZvY2F0aW9uIjogWwogICAgICB7CiAgICAgICAgImlkIjogIiN6Nk1raGRtekZ1NjU5Wko0WEtqMzF2dEVEbWp2c2k1eURaRzVMN0NhejYzb1AzOWsiLAogICAgICAgICJ0eXBlIjogIkVkMjU1MTlWZXJpZmljYXRpb25LZXkyMDE4IiwKICAgICAgICAicHVibGljS2V5QmFzZTU4IjogIjRCV3dmZXFkcDFvYlFwdExMTXZQTmdCdzQ4cDdvZzFpZTZIZjlwNW5UcE5OIgogICAgICB9CiAgICBdLAogICAgImNhcGFiaWxpdHlEZWxlZ2F0aW9uIjogWwogICAgICB7CiAgICAgICAgImlkIjogIiN6Nk1rdzk0QnlSMjZ6TVNrTmRDVWk2Rk5Sc1duYzJERkVlRFh5QkdKNUtUelNXeWkiLAogICAgICAgICJ0eXBlIjogIkVkMjU1MTlWZXJpZmljYXRpb25LZXkyMDE4IiwKICAgICAgICAicHVibGljS2V5QmFzZTU4IjogIkhnbzlQQW1mZW94SEc4TW4yWEhYYW14bm5Td1Bwa3lCSEFNTkYzVnlYSkNMIgogICAgICB9CiAgICBdLAogICAgImFzc2VydGlvbk1ldGhvZCI6IFsKICAgICAgewogICAgICAgICJpZCI6IiN6Nk1raXVrdUF1UUFFOG96eHZtYWhuUUd6QXB2dFc3S1Q1WFhLZm9qandiZEVvbVkiLAogICAgICAgICJ0eXBlIjogIkVkMjU1MTlWZXJpZmljYXRpb25LZXkyMDE4IiwKICAgICAgICAicHVibGljS2V5QmFzZTU4IjogIjVUVnJhZjlpdGJLWHJSdnQyRFNTOTVHdzR2cVUzQ0hBZGV0b3VmZGNLYXpBIgogICAgICB9CiAgICBdCn0=

@OR13 how bad of an idea is this?

[OR13]

This is pretty cool idea, you can I proposed something similar for sidetree / ipfs a while back...

essentially, you delete the id property before hashing the document, and inject it before consumption.

Imo its not a terrible idea.

[tmarkovski]

This might make the URI a little long, but one can also append a signed-ietf-json-patch parameter after initial-state with { "op": "replace", "path": "/id", "value": "did:new:updated" } to communicate did rotation from self certifying did doc in a single URI statement.

[llorllale]

Strong +1 to using signed-ietf-json-patch if using long URIs becomes palatable to the DIDComm working group.

[dhh1128]

@OR13 recommended signed-ietf-json-patch a while back (see #24). I think it's a good idea; I just haven't acted on it yet due to distractions. But it's important to understand that we would have to layer some restrictions or semantics on top of it, because not every valid patch to the JSON of a DID document should be allowed (in other words, signed-ietf-json-patch allows for possibilities that our DID method should disallow). We need something that is analogous to a database transaction, where changes that are intended to be combined (delete old key, add new key, update service endpoint) are part of a single atomic patch, and changes that are not intended to be part of the same atomic unit are required to be pushed into a different patch even if the format could combine them. This is because the deltas that we communicate represent discrete changes to how security is evaluated.

[OR13]

yes, ideally you would do this:

1. pre patch did document
2. validate path
3. apply patch (JSON Schema)
4. validate post patch did document  (JSON Schema)
5. rollback to 1 if your schema fails

This gives you lots of flexibility and security without needing to add yet another patch type for every new DID Document feature... you just update your schemas to allow that feature.

I tried to get sidetree to work like this, but ultiamtly they decided to implement a patch type per did feature, so there are patches for public keys and services.... and no way to provide arbitrary json.... UNLESS you used ietf-json-patch.... which AFAIK, Microsoft still does not support.

[TelegramSam]

@kdenhartog What you propose sounds nice, but does not really meet the goals of Method 2. Are you proposing it as a replacement, or useful for another purpose?

[kdenhartog]

@kdenhartog What you propose sounds nice, but does not really meet the goals of Method 2. Are you proposing it as a replacement, or useful for another purpose?

A replacement. Which goal is it not addressing?

[dhh1128]

A replacement. Which goal is it not addressing?

It is replacing a ~300 byte DID with a ~2000 byte DID. I don't think it addresses terseness.

[kdenhartog]

It is replacing a ~300 byte DID with a ~2000 byte DID. I don't think it addresses terseness.

Thanks, I hadn't seen any goals listed in the comments or this PR, so wasn't sure. Could we add a list of them somewhere to align what the problems we're trying to solve are?

It's worth noting the initial-state only needs to be passed in the first message and subsequent updating of states later on. Additionally, with the alternative proposal that I mentioned we get to keep state updates at this layer rather than having to rely on the protocol layer above handling did rotation capabilities. In @TelegramSam proposal did document updates don't seem possible which would seem to limit the functionality of this method in similar ways that did:key gets limited. Is that not a goal that needs to be addressed at this point?

[dhh1128]

Is that not a goal that needs to be addressed at this point?

There is already a robust method for updating state (method 1). It calls for exchanging deltas in a formal protocol, and there is a PR that reframes it to use initial-state. Modifying it further to use signed IETF JSON patches would be another nice enhancement. What you are proposing, Kyle, feels like the feature equivalent of that method.

Sam's method intended to strike a middle ground -- more sophisticated than did:key (method 0) in that it allows multiple keys and an endpoint, but less fancy than method 1 because it disallows updates. Sam's proposal also attempted to address the requirement that we would communicate these DIDs in messages represented as QR codes. That's where the need for terseness comes from.

[kdenhartog]

Is that not a goal that needs to be addressed at this point?

There is already a robust method for updating state (method 1). It calls for exchanging deltas in a formal protocol, and there is a PR that reframes it to use initial-state. Modifying it further to use signed IETF JSON patches would be another nice enhancement. What you are proposing, Kyle, feels like the feature equivalent of that method.

Sam's method intended to strike a middle ground -- more sophisticated than did:key (method 0) in that it allows multiple keys and an endpoint, but less fancy than method 1 because it disallows updates. Sam's proposal also attempted to address the requirement that we would communicate these DIDs in messages represented as QR codes. That's where the need for terseness comes from.

This makes it far more clear to me what's trying to be achieved in this PR. Based on that, I agree that this wouldn't align with the goals well. Thanks for the additional information. I'll move my discussion to the improvements discussed in method 1 rather than detract from the work on method 2 here with the original approach. I'll take a look at it from this new lens as well to see if I might be able to help optimize for the goals as well.

Just so I'm understanding correctly the priorities of method 2 are:

1. terse DID
2. Self-inflating did document
3. Capable of expressing multiple keys, the associated proofPurposes, and service endpoints
4. Is self certifying

Is there any other ones that aren't mentioned above that should be considered?

[kdenhartog]

Have you taken any consideration into how you would encode an uncompressed public key? For example, P-256 keys often include both an x and y coordinate rather than using a compressed form made possible with Ed25519 keys. In the case where the key is 2 coordinate points can we specify how ordering of the points should be handled? Additionally with RSA keys do we want to assume that the exponent ("e" in JWK) would always be "AQAB" and that the encoded value will always be the modulus parameter (n in a JWK)? Some more info on how to encode different key types would help here.

[TelegramSam]

using multi-base multi-codec keys allows us to support any key that can be encoded in those methods. Is that not sufficient?

[kdenhartog]

I've not found anywhere that defines how it should work. Can you point me to where you're finding them defining how those questions are specified? Even Ed25519/X25519 keys are not defined well anywhere from what I can find. All of the multicodec bytes are registered, but I can't find anywhere that specifies things for the questions I raised.

[dhh1128]

Is there any other ones that aren't mentioned above that should be considered?

No, I think your summary of requirements is excellent.

[dhh1128]

I think this PR has been discussed 3 or 4 times on community calls. The conversation stream here has been excellent as well. The open question by @kdenhartog about advanced key properties is an interesting one, but I don't want to hold up the PR for it, so let's move that to an issue. The other proposal that Kyle made is quite interesting, but represents a method with different goals than the Method 2 Sam has proposed. Therefore, I suggest we move that to a new PR.

I'm going to go ahead and merge this one.