Key management in FAPI2 Advanced

[Dave Tonge]

Should we be prescriptive?

Maybe require jwks_uri

Should there be any discussion on key re-use between JAR/JARM/HTTPSig/DPoP

[Dave Tonge]

Initial PR here: https://bitbucket.org/openid/fapi/pull-requests/322/pull-in-key-management-clauses

This just brings in some clauses from FAPI 1

[Brian Campbell]

The clauses from FAPI 1 are fine but don’t deal with RS keys or RS access to client keys (the client is registered with the AS).

And DPoP keys are more dynamic and not in client metadata.

[Dave Tonge]

We have the following keys:

• Client DPoP
• Client HTTP Sig
• Client JAR
• Client private_key_jwt
• Client MTLS
• AS JARM
• AS Introspection Response
• AS HTTP Sig
• RS HTTP Sig

Is it ok for a client to use the same key for DPoP, HTTPSig, JAR, private_key_jwt?

All requests to an RS will have an access token. That access token will be sender-constrained either with DPoP or MTLS. If using DPoP, can a client use the same key for DPoP to sign the http message? That would keep it simple for the RS.

In the context of non-repudiation, the key used to sign may be registered at a trusted third party (e.g. a directory service).

For RS to get HTTP Sig public key for Client we have the following options:

1. Client uses same key for DPoP and HTTP Sig (requires DPoP)
2. RS gets client_id (either via introspection or JWT access token or MTLS certificate) and looks up key by client_id, key_id either at AS or trusted third party.

‌

[Dave Tonge]

I've merged in the PR that add jwks_uri recommendations. We agreed to not provide specific guidance on re-use of keys for different purposes