[has-PR] Signed request - what is the audience?

[David Waite]

OAuth Core and RFC9101 (JAR) have a SHOULD requirement for ‘aud’, and that it SHOULD be the issuer.

However, we changed SIOPv2 to equate iss and sub, and we will not know sub at the time of the request (since the end user has not yet been authenticated).

I think we should define exact behavior here, and propose one of:

1. The aud of a signed request SHOULD be omitted
2. The aud of a signed request SHOULD be the entity identifier associated with a set of SIOP feature policy. (e.g. https://self-issued.me/v2 as a default indicating the static metadata, potentially another value for a different trust framework).
3. The aud of the signed request SHOULD be the authorization endpoint of the SIOP.

(edit: changed proposal MUSTs to SHOULDs)

[Kristina Yasuda]

Could you please elaborate why ‘isss’ == ‘sub’ leads to changes in ‘aud’? I am missing something

[David Waite]

Sure, I’ll elaborate.

JAR and OpenID Core define a SHOULD for the aud claim in the JWT - that it SHOULD be present and SHOULD be the issuer identifier. For OpenID that would be the OP identifier.

https://openid.net/specs/openid-connect-core-1_0.html#RequestObject

https://datatracker.ietf.org/doc/html/rfc9101#section-4

However, SIOPv2 now says that the OP identifier/issuer is the subject identifier - it is self-issued. In v1, there was a single issuer with every SIOP as a node in a quasi-distributed system, now each issuer is unique.

This means however that the RP will usually not know the subject identifier/issuer identifier to use at request time, since the purpose is to authenticate the end user. So this SHOULD becomes difficult to follow.

My argument is that we must give new guidance here, because the SIOP has requirements for aud processing on the request object set by the JWT spec:

https://www.rfc-editor.org/rfc/rfc7519.html#section-4.1.3

If the principal processing the claim does not identify itself with a value in the
"aud" claim when this claim is present, then the JWT MUST be rejected.

The full argument is that if

1. A RP, thinking they SHOULD set audience, sets it to a value that they suppose to be correct, and
2. A conformant SIOP, seeing that they MUST evaluate audience, doesn’t have the same interpretation of what a correct aud claim for SIOP is, then
3. the two will not be interoperable, because the JWT spec says the token MUST be rejected

‌

[Kristina Yasuda]

discussed during SIOP call. needs more eyes.

[Kristina Yasuda]

suggest we omit aud for SIOP… AS/SIOP will know it is SIOP req from client_id, right?

[Nat Sakimura]

I am a strong believer that the verification steps should be uniform.

If the `iss` is what it used to be in v.1, this problem does not arise, is it correct? If it is the case, why did we make the change?

[Kristina Yasuda]

PR #120, Issue #1400 explains the logic.

but in short, OIDC Core defines iss as "Issuer Identifier for the Issuer of the response", which is a user in SIOP.

also because SIOP v2 allowed dynamic discovery in which case iss=self-issued.me does not fit.

[Michael Jones]

PR #288 removed aud from the fetch endpoint, for these reasons.

[Kristina Yasuda]

The rationale why it was removed openid / connect / Pull Request #288: chore: [Federation] terms and EC refactoring — Bitbucket.

I think we may want the same direction in SIOPv2 - do not mandate aud in the signed request.

[Kristina Yasuda]

PR #294

[Torsten Lodderstedt]

The way I read https://bitbucket.org/openid/connect/pull-requests/288/chore-federation-terms-and-ec-refactoring#comment-325007138, “aud” was removed in the signed response because the caller was not authenticated/unknown. I’m not sure that’s the case in SIOP as well.

SIOP v2 needs to distinguish between the issuer of the id token (the user) and the service processing the request. We also had discussions to add attestation for this service (via JARM), i.e. we will need to identify this service as issuer of the signed response. We can use the same value in the request.

In case of dynamic discovery that shouldn’t be a problem. In case of static discovery, we could only use a static value.

So I’m not sure removing the aud is the right way.

[Kristina Yasuda]

PR merged