Should we specify algorithms for asymmetric signatures in authentication JWTs?

[jmandel]

Right now we're silent on this. Should we pick one or more algorithms as "must support" if we want consistency? e.g. RS256?

[isaacvetter]

Here's a similar conversation in CDS Hooks: https://github.com/cds-hooks/docs/issues/187

[daliboz]

Also, encryption is currently called out in the registration section. Once we land this, we may want to move this to the section calling out how to get a token.

If we do choose some algorithms, we should target minimums since these are always changing and improving. Also, it probably needs to be specific as to the JWA being used for the signature (does the current spec mean the JWT will be signed with RSASSA-PKCS1-v1_5 or RSASSA-PSS?)

[jmandel]

We should plan to follow what the CDS Hooks group is deciding on, and say:

• servers should support both ES384 and RS384
• clients should should at least one of ES384 or RS384

(Or even "must".)

Any concerns with this level of specificity, assuming we also pull in the rest of the guidance from https://github.com/cds-hooks/docs/issues/187#issuecomment-395227390 ?

[jmandel]

Will plan to adopt finalized language from https://github.com/cds-hooks/docs/issues/187#issuecomment-397082755 with a note that we recommend that the server (I.e. the actor verifying signatures) should be able to verify signatures with both recommended algorithms (i.e., RS384 and ES384).

Note: re "or better" we probably want to just say that actors can choos different algorithms over time as their neds change. (better vs worse usually isn't black and white).

[lcmaas]

What is the rationale behind recommending RS384/ES384 as the "floor" instead of RS256/ES256?

We are talking about signatures on very short-lived JWTs here, not signatures that will need to validated far into the future. As points of reference, NIST SP 800-57 allows the use of RS256 with 2048 bit keys for signatures that need to be validated prior to 1/1/2031. ES256 and RS256 with 3072 bit keys go even beyond that, and support for both of these algorithms (RS256+ES256) is already recommended in RFC 7518 and 7519. Also, RS256 is the default algorithm to sign OIDC ID tokens at this time.

[jmandel]

The near-term rationale was simply alignment with the decision from the CDS Hooks workgroup; if we're going to make a specific recommendation, we wanted to be consistent.

[jmandel]

Closed by https://github.com/smart-on-fhir/fhir-bulk-data-docs/pull/46