OP must accept 'aud' in client assertion as issuer

[Joseph Heenan]

See https://bitbucket.org/openid/fapi/issues/398/new-certification-check-aud-in-client - it was discussed on today’s call and we felt that we should probably add a normative clause in FAPI2 that requires the OP to accept the issuer as the aud for client authentication assertions (along with the token endpoint as per OIDC and the url the assertion is being sent to as is also sometimes currently done). This is to aid interoperability.

[Takahiko Kawasaki]

I agree with Joseph.

[Dave Tonge]

Suggested wording:

shall accept its issuer value in the aud claim received in client authentication assertions

@daniel ?

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/276/add-normative-clause-for-as-to-accept

[Dave Tonge]

We had a lot of discussion about this today. I’ve updated the PR as follows:

1. Required the client to use the issuer value
   2. Required the AS to accept the issuer value
   3. Allowed the AS to accept other values (i.e. token endpoint or the endpoint the assertion was sent to)

I think this meets the aims of nudging the ecosystem towards using the issuer value for client assertions, but avoids Authorization Servers from being penalized for allowing other values.

While we are aiming for interoperability in FAPI 2.0 - I personally feel that this achieves a realistic balance.

It would be good to get any feedback on the updated PR as soon as possible.

For those not on the call the discussion ranged about:

1. Can we make breaking changes? Is that not the purpose of FAPI 2.0?
2. Existing products would end up with lots of logic branches for not much security benefit
3. Do we need to list all the allowed endpoints (CIBA/PAR/Token)

I will open another issue for the question of multiple audience values.

‌

[Dave Tonge]

The PR has already been merged