Adopt ES256K JWT id_token for DID Auth, issued by Issuer and Verifier Web Servers

[OR13]

The issuer website needs to challenge a DID to sign a QR code (more details in future tickets).

In order for the issuer to authenticate the subject, the issuer and subject need to agree on a ciphersuite.

jose based jwt is the most interoperable, I strongly suggest we use it.

We even have https://github.com/decentralized-identity/did-auth-jose

I'd like to see RSA here, since its likely to be equally unpopular with all members, and its also well supported by languages.

I think OIDC SIOP is out of scope for this.

There is some summary here:

https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md

I think we need to agree to a simple JWT Challenge Response flow for the purposes of authentication.

This package is also linked on the credential format ticket:

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

To my knowledge it supports all the key types we need, so if we adopt JWT / JWE with this package I think we can close this ticket.

[OR13]

@awoie If you could add an explanation of how OIDC SIOP might be used here, we can maybe consider supporting it, but it seems more complicated than implementing a simple challenge response flow from the Issuer / Verifier Web Servers.

I propose we adopt ES256K JWT id_token (Bearer) as the authentication mechanism for the Issuer and Verifier Web Servers.

[awoie]

@OR13 DID AuthN OIDC SIOP is a simple challenge/response protocol based on JWTs. You could easily encode the SIOP request in a QR Code. The SIOP spec allows different response_mode values, i.e., fragment, form-post, query which determine the way the response will be sent back to the requester. All of them use HTTPS.

The downside is that it has some extra payload for OIDC-compliance such as sub_jwk that contains the public key of the Identity Wallet in addition to the did. SIOP is in the OIDC core spec but is not widely adopted so far, but it uses the same or very similar request/response messages. The reason for that adoption rate is that it was specifically designed for interacting with a mobile app, and there are not so many atm. After speaking to OIDC implementers, they mentioned that they would support SIOP if there is more traction. With this, we could potentially interoperate with traditional OIDC RPs.

[OR13]

@awoie Seems like we may be able to create the first implementation of this for the interop project use case.

The issuer server creates the challenge JWT and renders it.

The subject uses (app / script) to sign the challenge with a key linked to their DID, and produces a response JWT.

The subject submits this response to the issuer server.

The issuer server constructs an id_token and returns it to the subject.

The subject is authenticated.

I think such a flow is achievable, and it is possible for it to be spec compliant.

If there is no off the shelf javascript implementation of this, I still think it can be supported as the auth flow for interop project, but subject wallets might not implement it in time for demoing.

Having a script fallback should solve that problem.

At the end of the flow is an id_token signed by the issuer server, with keys available via /.well-known/openid-configuration?

The confusing part for me is that the iss and sub are both DIDs, and the wallet stuff seems orthogonal. The JWTs need to be signed, nobody should care how, the openid:// bit is just so that the messages can be delivered.

Can you provide JWT examples like you did for the credential format?

[kdenhartog]

RSA won't support repudiable authentication using the methods already described in the JOSE spec. The way it works is to encrypt the encryption key using RSA-OAEP. Since RSA-OAEP doesn't have any ties to the sender's public key, we can't verify the sender in a repudiable way.

If we supported RSA DHKE, then we could handle this, but as far as I can tell this is not a registered alg on JOSE IANA registry.

We can take the ECDH-SS method from the COSE IANA registry and handle this with any ECC key types. With that in mind, we could use ES256 (Secp256r1) or ed25519 which are registered in the JOSE IANA registry and add the ES256K (Secp256k1) to the registry.

It's worth noting that as of right now the JOSE IANA registry will require additions no matter which method we take (some are much easier than others e.g. re-register COSE algs to JOSE) if we want to handle repudiable authentication, which I believe we should make a requirement because it sets good privacy by default precedents.

[awoie]

For the non-repudiable part one could potentially use RS256 for JWT/JWS although my preference would be ES256K, or Ed25519 . This is what we discussed in the course of the SIOP profile. But I agree, for repudiable authentication in JWT/JWE (envelope), i.e., pack/unpack, we should stick with what we have discussed so far, i.e., X25519 and XChacha20. Currently, we got confirmation that XSalsa20 cannot be used with AEAD which is a requirement for JWEs.

The conclusion is that we have to support the crypto that identity wallet provider require. In case of did:ethr, the underlying signature algorithm is ES256K.

[awoie]

@OR13 Because SIOP DID AuthN still needs external reviews, we could propose a minimal version of the SIOP DID AuthN profile for the interop project: https://github.com/decentralized-identity/authentication-wg/issues/1

[OR13]

@awoie I'm gonna close this, as we have adopted OIDC SIOP and now need to consider what an implementation will cost: https://github.com/decentralized-identity/interop-project/issues/14