restricting 'aud' in request object to a single value

[Joseph Heenan]

https://tools.ietf.org/html/rfc7523#section-3 and https://openid.net/specs/openid-connect-core-1_0.html#RequestObject both allow 'aud' in the request object to contain any array containing more than one value (as well as a simple string as used in most examples).

This just seems to me to be unnecessary flexibility and also flexibility that I think a large number of people don't appreciate, both of which feel bad to me in the context of a standard that aims to be higher security. (I would also bet some Authorization Servers in the UK OpenBanking ecosystem only actually support a single string currently.)

I can't see any FAPI use case where a request object would need to have multiple aud values.

I would be tempted to restrict 'aud' to being a simple string value.

The language in the various standards about what value 'aud' should take is also a bit loose (e.g. OIDCC says "The aud value SHOULD be or include the OP's Issuer Identifier URL." - i.e. it's a recommendation, not an absolute requirement), it might be worth FAPI stating that it MUST be exactly the AS's issuer value.

[Nat Sakimura]

Need to assess the impact by looking at the implementation configurations.

[Joseph Heenan]

@RaidiamRalph Sorry, I couldn't reply to your points on the call as my network dropped out.

My current belief is that none of the OB banks /require/ multiple audiences to be sent in the request object (because if they did they would fail the conformance suite).

I'm not sure if any banks actually allow multiple audiences to be sent. We will have a test for it shortly. The test requires (as per my understanding of the current state of the spec) that a bank accepts a request object with the aud claim looks like this (for example this one is for ozone/referenco):

"aud": [ "https://referencobankauth2018.o3bank.co.uk:4102", "https://other1.example.com", "invalid" ],

I suspect many banks won't actually accept request objects like this. Unfortunately (banks being banks) I'm not sure any of them will actually run the test anytime in the next few months.

[Brian Campbell]

IMHO it's okay to require that the client set the aud claim as a single value. But it is unnecessarily overreaching to mandate that the OP enforce that aud be single value.

[Dave Tonge]

Merged in josephheenan/fapi/restrict-aud (pull request #95)

FAPI-RW: Require the 'aud' claim in the request object

Currently the request object an RP generates for one OP may well be accepted by another OP. This seems undesireable and hence we strengthen the 'should's found in https://openid.net/specs/openid-connect-core-1_0.html#RequestObject to MUSTs, as discussed is #190.

It is left unspecified what happens if a client sends a request object where the aud is an array, particularly in the case where it contains audiences other than the AS's issuer.

closes #190 closes #214

Approved-by: Brian Campbell [e-mail] Approved-by: Dave Tonge [e-mail]

→ <<cset be897f6c48de>>