How To Deal With The Case When The Intended Audience Is Not The Releasing Party

Session Topic: OIDC and SAML2: How to deal with the case when the intended audience is not the relying party

Wednesday 5G

Convener: Roland Hedberg

Notes-taker(s): Roland Hedberg

Tags for the session - technology discussed/ideas considered: How to make an IdP (SAML2) or an OP (OpenID Connect (OIDC)) set the correct audience in an assertion or an id_token. That is when the SP/RP knows it is not the ultimate receiver and also knows who the correct one is.

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: Three examples of the problem:

UMA: where an Authorization Server needs extra information about the requestor from the client. The client will act as the SP/RP against an IdP/OP to gather the necessary information but the client is not the intended audience the AS is.

Token exchange: There are cases where a issued id_token must be exchanged for a SAAS token. Again the receiver of the id_token is not the intended audience the SAAS token exchange service is.

Proxys: An effect of the design. A proxy exists in two environments and wants to transmit information received in one to the other.

There is no way either in SAML2 or in OIDC for the RP/SP to signal the OP/IdP who the intended audience is. To change this in SAML2 is probably very hard, to change it in OIDC is probably doable so we took that as an action item.