Closed adeinega closed 4 months ago
There are various types of JWTs, with all kinds of different purposes (SETs, OpenID Connect logout tokens, OpenID Connect Federations Trustmarks), not all of them are good candidates to be exchanges so I highly recommend to use & be focused on JWT ATs and OpenID Connect ID Tokens.
Suggested changes are in https://github.com/deansaxe/wimse-token-exch-design-team/pull/19.
I believe the specification should require (or at least, strongly recommend) an AS to be included in the aud claim when it exchanges one token into another, that applies for
this is a countermeasure against both misuse, and replay attacks, especially in cases, when an AS in one security domain exchanges one of these tokens from another (security) domain. I tend to think that OpenID Connect ID Token isn't a very good candidate to be exchanged for something else, it's impossible to deny this use cases is an extremely popular one in the wild... However, it's a mechanism to pass claims about the authentication of user to an RP and they don't necessary include all information about a user (the subject could be opaque, etc.) to issue an AT for it. Furthermore, ID Token could be easily encrypted by an OP and decrypted only by an RP using its public keys. Interestingly enough, the OpenID Connect spec, allows ID Tokens to be unsigned in certain cases. Lastly, the OpenID Core specification doesn't define a dedicated value for the typ claim for its ID Tokens, that makes it hard to distinguish them from other JWTs.
Please also remember that OpenID Connect ID Token, as well as other above mentioned ATs can be passed around using the front channel.
The spec should be specific about allowed exchange types for SAML assertions (only assertions from SAML IDPs need to be allowed).