Adopt ES256K JWT as Credential Format

[OR13]

I recommend ES256K (Unencrypted) JWT for Credential and Presentation, see the format proposed by @awoie below.

[OR13]

@panva/jose requires node 12 which conflicts with a bunch of other libraries like web3. We probably want to use JWS / JWK but may not want to use that library.

[OR13]

If this issue does not receive significant comments / criticism, I recommend we adopt JWT as the format, and rely on credential wrapping as needed to support wallet integration down the road.

[coder5876]

@OR13 Do any of the major JOSE/JWT libraries support ES256K out of the box? I would guess they only support ES256 (which is NIST P-256 curve).

[coder5876]

@OR13 Just checked here

https://www.npmjs.com/package/@panva/jose

and it seems this library has indeed implemented ES256K support.

[OR13]

@christianlundkvist I have tested https://github.com/uport-project/did-jwt and found that it does work with node 12 / panva/jose.

I have not tested https://github.com/decentralized-identity/did-auth-jose , but in theory it should work.

node 12 supports secp256k1 out of the box, with non deterministic k signatures.

But node 12 is not usable with many versions of web3, I think we will likely need a small ES256K library.

I have one built with web assembly runs in browser and on node but it is not published yet.

If wallet apps need to verify signatures on credentials, we will need a list of supported architectures.

[csuwildcat]

I would like to make the case for supporting three variants: secp256k1, RSA, and ED25519. We did a DIF member survey a while back, and literally everyone fell into these three. If we must reduce to one, secp256k1 was by far the most used. Just my 2c

[OR13]

If we accept standard JOSE and soon to be adopted JOSE, we will have support for these 3.

These are the related RC RFC / drafts. They are well enough documented to be implemented, and there are implementations out there, like the one above.

https://tools.ietf.org/html/rfc8037 https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-01

For the Credential format to be fully specified, additional information is required however.

• ES256k for secp256k1
• RS256 for RSA
• EdDSA for Ed25519

These are 3 fully supported JWT alg, if we choose to adopt all 3, the choice for the issuer will become which to use, and how to know, and can BTC-R support these 3 key types.

On a related note, I believe we should require all publicKeyJwk to include a conformant kid per:

https://tools.ietf.org/html/rfc7638

[OR13]

@kdenhartog Does DIDComm support these 3 formats ^ ? / can we agree it will ; )

[OR13]

A JSON-LD alternative to JWT: https://github.com/digitalbazaar/vc-js

I don't think this is a good idea for the interop project because there seems to be less support for JSON-LD Signatures and Credential formats than JWT, but I could be convinced by a strong counter argument. I do love JSON-LD, and I have used related libraries before.

[kdenhartog]

Yes DIDComm credential exchange protocol can support any arbitrary credential format and support a variety of crypto suites. However, the project in DIF (DIDComm-crypto-js) is not related to handling VCs. It's intended to be the "cryptographic envelope" to send arbitrary semantic messages. One of which might be the credential exchange protocol messages.

I have been exploring what it would take to support additional cryptosuites for the "crypto envelopes". More details to come later on that.

[awoie]

I agree with @csuwildcat observation. We did a survey and secp256k1 (ES256K) was supported by most ppl. In the DID Auth WG we reconfirmed that ES256K, Ed25519 and RS256 are the algorithms we want to support.

uPort is working on a VC JWT library and we are intending to move that library to DIF. The library will have support for ES256K, ES256K-R and Ed25519 (Nacl).

@pelle could you provide more info when this will happen?

[awoie]

@OR13 @rado0x54 The credential format that you proposed is not W3C compliant.

We could use the following minimal W3C VC JWT profile:

updated iss to be a did:

{
    "alg": "ES256K",
    "typ": "JWT",
    // (optional) don’t use kid if you only have one verification key
    // in your DID Document
    "kid": "did:example:abfe13f712120431c276e12ecab#keys-1"
}

{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "fasdfasdfsdfa",
  "iss": "did:example:asdf",
  // iat is not part yet part of the W3C spec but mentioned
  // in the implementation guide. This is due to issuanceDate’s semantic
  "iat": 1541493724,
  "nbf": 1541493724,
  "exp": 1573029723,

  // .. add JOSE specific claims here

  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": ["VerifiableCredential", "UniversityDegreeCredential"],
    "credentialSubject": {
      "degree": {
        "type": "BachelorDegree",
        "university": "MIT"
      }
    }
  }
}

And for the W3C presentation we could use:

{
  "alg": "ES256K",
  "typ": "JWT",
  // don’t use kid if you only have one verification key
  // in your DID Document
  "kid": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1"
}

{
  "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "aud": "did:example:4a57546973436f6f6c4a4a57573",
  "iat": 1541493724,
  "nbf": 1541493724,
  "exp": 1573029723,

  // .. add other JOSE/IANA claims here such as “nonce”

  "vp": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": ["VerifiablePresentation", "CredentialManagerPresentation"],
    // base64url-encoded JWT as string
    "verifiableCredential": ["..."]
  }
}

[OR13]

@awoie thanks, my proposal was a straw-man. These are excellent format suggestions, I'll edit the issue to reflect using them.

[OR13]

I'm going to consider this adopted, and update the readme to reflect the decision.