Clarify that the ID Token is still only for internal RP use

[fkj]

This issue is a copy of my request on the AB/Connect mailing list. I am reposting it here to make it easier to keep track of it.

To further clarify that the ID Token is only for "internal" RP use, I think you should expand the note in section 2 (Privacy Considerations) with something like: "The RP Authenticating Component MUST NOT share an ID Token with any component not controlled by the RP."

(this issue was porte from: dickhardt/openid-key-binding#10)

[fkj]

Here are some take-aways from discussions I had at IIW:

• Key Binding spec should say that RPs MUST NOT send the ID token with the bound key to RPs outside their control, and enumerate the security and privacy risks of doing so to explain why.
• One interesting option in case you really need to do this is to encrypt the ID Token JWT and only share the decryption key with trusted actors.
• RPs are potentially putting the OP’s users at risk by sharing the ID token with other entities (e.g. in the Docker case).

[JonasPrimbs]

Here are my thoughts from today's OpenID meeting:

• Turning the ID token into a key-bound ID token is only a good idea if the key-bound ID token remains in the same trust boundaries as the classic ID token. Otherwise, we will get legacy issues.
  • Solution: Issue a dedicated key-bound ID token in addition to a classic ID token
• By defining what an "RP" is between whose components a key-bound ID token can be shared, we overcomplicate the specs and limit their applicability.
  • Suggestion: Allow the RP to share a key-bound ID token with third parties. To ensure security and data protection, restrict the token's audience to the expected third-party RP identifier, and inform the end user in the consent screen that the RP may share the requested data with the third-party RP.