JWE / DIDComm Integration

[OR13]

The spec notes the use of JWE, which is also used by DIDComm.

https://digitalbazaar.github.io/encrypted-data-vaults/#example-3-example-encrypted-document

I would like to see concrete examples of supported JWEs, including the key material necessary to decrypt, and compare for interoperability with the DIDComm encrypted envelope format. There is no DIDComm spec yet to point too, but the intention is for the encrypted envelope to be a JWE compliant.

[OR13]

Also wondering if JWT was considered, since it could theoretically be used to support public signed information in the future... As I understand edv, there is intentionally no support for storing of signed plaintext.

[dmitrizagidulin]

@OR13 - Sure thing, I'll see if I can rustle up an example JWE, with key material.

As I understand edv, there is intentionally no support for storing of signed plaintext

That's exactly it, yeah, one of the core design considerations says "To accomplish this, the data must be encrypted both while it is in transit (being sent over a network) and while it is at rest (on a storage system)." And that needs to be capitalized to MUST be encrypted, because for various reasons (mostly having to do with plausible deniability), vaults should never ever store plaintext (even if it's signed).

Now, whether or not that requirement can survive the standardization process (because like you've seen from the EDV/Data Hub sessions at IIW, several parties want to be able to store non-encrypted data) remains to be seen, but for now, it's intentional.

[OR13]

It may be helpful to retain the distinction, possible that these other concerns will be solved in another layer, like Agents or other Hub Extensions, etc...

[dmitrizagidulin]

@OR13 Here's an example document with envelope:

{
  "id":"z19x9iFMnfo4YLsShKAvnJk4L",
  "sequence":0,
  "indexed":[
    {
      "hmac":{
        "id":"urn:mockhmac:1",
        "type":"Sha256HmacKey2019"
      },
      "sequence":0,
      "attributes":[

      ]
    }
  ],
  "jwe":{
    "protected":"eyJlbmMiOiJDMjBQIn0",
    "recipients":[
      {
        "header":{
          "kid":"urn:123",
          "alg":"ECDH-ES+A256KW",
          "epk":{
            "kty":"OKP",
            "crv":"X25519",
            "x":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs"
          },
          "apu":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs",
          "apv":"dXJuOjEyMw"
        },
        "encrypted_key":"4PQsjDGs8IE3YqgcoGfwPTuVG25MKjojx4HSZqcjfkhr0qhwqkpUUw"
      }
    ],
    "iv":"FoJ5uPIR6HDPFCtD",
    "ciphertext":"tIupQ-9MeYLdkAc1Us0Mdlp1kZ5Dbavq0No-eJ91cF0R0hE",
    "tag":"TMRcEPc74knOIbXhLDJA_w"
  }
}

[OR13]

I take it this was generated with https://github.com/digitalbazaar/minimal-cipher

in the example urn:123 would be a DID key, like did:example:123#kid?

[dmitrizagidulin]

@OR13 Yeah, it was generated by minimal-cipher.

Hmm not sure about the key id -- @dlongley ?

[dlongley]

@OR13, yes, a DID key could be used. If someone wanted to advertise such a key so they could decrypt that JWE/document, then their DID Document would need to express that the key is authorized for the purpose of keyAgreement:

{
   "@context": "...",
   "id": "did:example:123",
   "keyAgreement": [{
     "id": "did:example:123#kid",
     "type": "X25519KeyAgreementKey2019",
     "publicKeyBase58" : "ztQ2JQy17Ue7bMGd2qYYbt1XX5awB7obHYyZgZmGieW"
   }],
   "..."
}

[OR13]

@dlongley

oooh.... why is keyAgreement not just publicKey? is keyAgreement in the did spec?

This is a really helpful example, Peer DIDs and DIDComm are working on very similar things, I really want to add an edv example to the interop project under DIF so there is a working implementation for people to prove interoperability against.

[OR13]

I can see easy interoperability path if we use publicKey instead of keyAgreement which is not currently supported by the spec AFAIK, I think its going to be hard to get DID Methods to add top level DID Document properties that are not publicKey, authentication, and services. We should do our best to use those IMO.

[dlongley]

@OR13,

oooh.... why is keyAgreement not just publicKey? is keyAgreement in the did spec?

It should be better explained in the spec. We're doing an insufficient job in the spec at the moment explaining that it's important for a DID controller to express authorization relations between the DID subject and its verification methods, and to express the purpose of a proof within a proof itself (or to ensure the purpose of some key usage is implicitly understood according to protocol).

This concept has been talked about at length in the CG but continues to be lost in translation from time to time; we need to clarify it more in the DID spec as the examples are currently doing the heavy lifting.

In short, verification methods (e.g., public keys) in a DID Document should be expressed according to what they are authorized for: authentication, capabilityInvocation, capabilityDelegation, keyAgreement, assertionMethod. This is safer than dumping them all into a bucket called publicKey which implies the DID controller has authorized any key therein for any purpose. It's an ambient authority model which is dangerous. Instead, the DID controller should be explicit about what the keys can be used for using these relations.

Then, for example, when a key is used in a proof, the proof can state what the proofPurpose is, which can match that authorization relation. This is why you see, in an LD proof, e.g., {.., "proofPurpose": "authentication"}. This allows a verifier to ensure that the key used was authorized by the DID controller for that purpose by matching the proof purpose up with a matching authorization relation in the DID Document.

There's more elaboration here: https://lists.w3.org/Archives/Public/public-credentials/2018Dec/0108.html

Note that sometimes a key type will implicitly restrict a key to really only having one purpose, but others will not. It would be quite unusual to use an X25519 key for anything other than keyAgreement, but I think it is best to always be explicit. There may also be some kind of crypto tool that could be used for both keyAgreement and something else in the future. So while keyAgreement isn't used in "proofs", it functions the same way. Such a key should be explicitly authorized for the purpose of keyAgreement, verifiers/decrypters should not allow it to be used for anything else (unless authorized by the DID controller by specifying such a relation between it and the DID subject).

I should also mention that, in practice, there are very few of these relations to define. I don't think it should be a significant interop concern.

[OR13]

@dlongley

I totally agree, but why not annotate the keys in the property that is already supported?

for example:

{
   "@context": "...",
   "id": "did:example:123",
   "publicKey": [{
     "id": "did:example:123#kid",
     "type": "X25519KeyAgreementKey2019",
     "proofPurpose": ["keyAgreement", "authentication", "assertionMethod"],
     "publicKeyBase58" : "ztQ2JQy17Ue7bMGd2qYYbt1XX5awB7obHYyZgZmGieW"
   }],
   "..."
}

There is a similar issue we are currently facing with the duplication or linking of keys in the authentication section.

For example this issue with well-known did configuration spec: decentralized-identity/.well-known#16

To demonstrate interop today, we are going to need to build on what people have implemented and is currently defined in the spec.

As I understand the proofPurpose in JSON-LD, the default assumption already exists for keys in the publicKey section that they are for assertionMethod. Seems like a shorter path to victory to add another field to the publicKey object than try and convince all the existing DID Method implementations to implement a property that is not in the did spec currently.

I'd prefer not to need to iterate a number of collections, and follow links between them if possible, the adoption of standard interoperability between DID Methods for things like OIDC SIOP or EDV will drive the method implementers to update their code, but I think we should try our best minimize the updates needed.

[dlongley]

@OR13,

I totally agree, but why not annotate the keys in the property that is already supported?

That would not be a statement linking the DID subject to what keys they have authorized but rather a statement about the key itself. What happens when the DID subject authorizes a verification method that is defined in another document and is perhaps under the control of another entity? What if that key expresses its usage for a whole variety of things ... but the DID controller only wishes to authorize one use for the DID subject? Rather, the authority should come from a relation explicitly stated linking the DID subject and the verification method -- because that is the root of authority, not meta data about the key.

To demonstrate interop today, we are going to need to build on what people have implemented and is currently defined in the spec.

There are implementations that use this today, including Veres One. Further, the spec does, today, mention proof purposes and shows examples differentiating between keys authorized for any purpose from those authorized for a specific purpose, for which authentication is an example. The problem might be that people have not understood authentication to be an "example" of one of these relations rather than "the only one". People may also extend DID Documents to create their own additional relations beyond those defined by either the DIDWG, LD proofs, the VCWG, or other groups.

As I understand the proofPurpose in JSON-LD, the default assumption already exists for keys in the publicKey section that they are for assertionMethod.

No, this is incorrect. Keys in the publicKey section simply do not specify what they are authorized to be used for. Referencing a key using assertionMethod as the property clearly expresses that it is to be used for that purpose. Strict applications should be looking for authorization relationships between the DID subject and the key, not in a publicKey catch all bucket.

I'd prefer not to need to iterate a number of collections...

Rather just the opposite happens with what I'm recommending. For example, verification software that sees an LD proof with a proofPurpose of X and then looks for the verification method under relation X in the DID Document. There's no iterating. If this does not exist, more iteration is required -- through all keys in publicKey ... as there is no explicit, specific, authorization relation.

[OR13]

@dlongley thanks this is much clearer now.

I now understand your point regarding the data stored in the publicKey property and the argument to use these other collections on the DID Document to handle specific purposes.

This section of the DID Spec needs to be updated:

https://w3c.github.io/did-spec/#did-documents

As you noted, people are assuming that publicKey, authentication and services are THE integration points.

If the intention is to use other collections, and not annotate the keys with purposes, we should provide a spanning example and update the spec asap.

I think we are probably fairly off topic for this issue now, but would love to support fixing the did spec.

Can you open an issue on the did-core spec and provide the most spanning example of these other collection properties, and tag me and I will add some details around why we need to get the spec updated?

[dlongley]

@OR13,

Thanks. There are already 2-3 issues related to this very problem open in the DIDWG so I don't want to add another. I've linked the issues (w3c/did-core#2). Ultimately, we need to develop spec text that will encompass the above conversation, the email from the archive I linked to above, and new text clarifying authentication and its meaning and relationship to the larger idea presented here.

[OR13]

Ready to move this issue https://github.com/decentralized-identity/secure-data-store

@msporny you should be able to do this now.