Decryption of JWE encrypted request in the case of Self-issued OP and multi-persona

[eijima]

e.g.) There are 2 personas in Self-issued OP - persona p1 and p2 - and some RP - rp1. End-user use rp1's service by both personas.

u1: user_id of p1 for rp1 k1: user_jwk(OP's public key) for p1. u1 = sha256(k1) // Standard 5.5 u2: user_id of p2 for rp1 k2: user_jwk for p2. u2 = sha256(k2)

issues) initial request: rp1 cannot encrypt the request (user_jwk is contained in the response)

subsequent request: rp1 encrypt the request with k2. OP cannot know that with which key the request is encrypted. So OP must try to decrypt with k1, k2, ... kn until the request is successfully decrypted.

if JWE header contains jwt(jwk's thumbprint. currently undefined) parameter like x5t, OP may be able to find the key easily. but it may be difficult to implement JWT/JWS/JWE library, because JWT library must also support key management.

[Michael Jones]

Couldn't the key ID (kid) parameter be used to disambiguate the keys, if necessary?

[eijima]

In Self-issued OP, all the OPs share the same name space. Thus, unless the JWK is always sent back in the response, which is a bloat in the response, kids like "1" or "2012-10-01" does not help. We need to somehow constrain the "kid" in the Self-Issued OP case so that the name crash does not occur. My proposal is to require the kid to be equal to user_id for Self-issued OPs.

THe main use case for using encrypted request is actually when doing prompt=none request with id_token that has some potentially sensitive claim values. If we change it to user_id in case of self-issued OP at least, OR allow login_hint to be used to carry user_id for prompt=none case, then we would not need the encryption and simplifies the life of RPs very much.

[Michael Jones]

This appears to be related to #668, which suggests a userinfo token.

Jun's solution proposes requiring the use of a collision resistent key ID in the self-issued case. We already have a collision resistent user_id. We could use that same value as the key ID.

The key ID would be needed when the client needs to encrypt the ID token to the IdP as a hint in the request or for other requests, or for other encryption from the client to the authorization server.

[John Bradley]

Re #657 update sec 3.3 to say that the sub is sent as the kid if the id_token is encrypted in the request.

→ <<cset 5ef8e12bbaf6>>

[John Bradley]

Fixed #657 Sec 2.1.1 Specify the sub is used as the kid if the request object or id_token_hint is encrypted

→ <<cset eb90df1e25ef>>

[John Bradley]

Re #657 Changed id_token to id_token_hint in Sec 2.3.1

→ <<cset e781fa4b88aa>>