Support for CryptoKey objects as private keys about client-js

[jmandel]

1. I don't see any reason to support asymmetric client authentication in IE.

2. It's not just "recommended" - my understanding is that IndeedDb is the only technically valid way to persist non extractable keys. But we could handle this case in the ways you suggest (allowing args to ready, or storing this particular property in IndexedDb).

3. Good call. It's okay to require a CryptoKey and an additional alg parameter if we need that to disambiguate.

4. As in (3) -- could even combine these into a publicJwk argument, which would have the full public key, alg, and kid...

[vlad-ignatov]

So, we could start with something like this:

interface ReadyOptions {
    privateKey?: JWK | {
        key: CryptoKey
        alg: "RS384" | "ES384"
        kid: string
    };
    clientPublicKeySetUrl?: string; // for jku
    [key: string]: any; // Other options TBD
}

FHIR.oauth2.ready({
    privateKey: {
        key: CryptoKeyObject,
        alg: "RS384",
        kid: "1234"
    },
    clientPublicKeySetUrl: "https://whatever"
}).then(client => ... )

Then, depending on if and how people use that, we may also consider IndexedDb.

My only question so far is why did you name this "publicJwk argument" above, instead of private - by mistake, or am I missing something?

[jmandel]

So, we could start with something like this

Yes, that would be a safe way to start

My only question so far is why did you name this "publicJwk argument" above, instead of private - by mistake, or am I missing something?

Oh, I was suggesting something like

FHIR.oauth2.ready({
    privateKey:  CryptoKeyObject,
    publicJwk: {
      "kty": "EC",
      "kid": "3Kfdg-XwP-7gXyywtUfUADwBumDOPKMQx-iELL11W9s",
      "use": "sig",
      "alg": "ES256",
      "crv": "P-256",
      "x": "11XvRWy1I2S0EyJlyf_bWfw_TQ5CJJNLw78bHXNxcgw",
      "y": "eZXwxvO1hvCY0KucrPfKo7yAyMT6Ajc3N7OkAB6VYy8",
    },
    clientPublicKeySetUrl: "https://whatever"

Just because the algorithm and the KID are already defined in that data model, but I am not pushing strongly for this suggestion.

[vlad-ignatov]

Looks like we are talking about the same thing. In my example, if privateKey has a key property, then it should have the shape { key: CryptoKey, alg: "RS384" | "ES384", kid: string }. Otherwise, privateKey is expected to be valid JWK having alg, kid and everything else.

What confuses me is that you have both privateKey and publicJwk. What is the idea behind using these together and why is that jwk public?

[jmandel]

Your suggestion works well! (I hadn't fully understood it when I suggested separately supplying the alg/kid in the context of a public key input.)

[vlad-ignatov]

This is now released in v2.5.0