aud should be mandatory in requests objects

[Joseph Heenan]

As I interpret the specs ( https://openid.net/specs/openid-connect-core-1_0.html#RequestObject ) currently RPs aren't required to included aud in the request object:

The aud value SHOULD be or include the OP's Issuer Identifier URL.

ie. this 'should' needs to be a 'must' in FAPI I think.

I am also dubious about the "or" part. An exact match seems like a better idea to me.

I suspect we need to do a fuller check on any other fields that are mandatory in request objects.

[Ralph Bragg]

Can we include language that requires this value to be advertised rather than serviced i.e as "as advertised on the well-known openid configuration" or some such

[Joseph Heenan]

https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-04 would make "aud" a must. (But I don't think we reference this document currently.)

[Joseph Heenan]

The Australian spec ( https://consumerdatastandardsaustralia.github.io/infosec/#infosec-profile-0-0-1 ) makes aud and iss mandatory in the request object:

Must contain the members 'iss' ('client_id' of DR) and aud (Issuer Identifier URL for the DH).

[Ralph Bragg]

it doesn't do any harm, it's already reference by the BCP and given that vendors will have to set this anyway in order to be compliant with AUS it's just another reason to pull it in as mandatory.

[Joseph Heenan]

As far as I know the BCP stops just short of making iss mandatory to send (assuming we're talking about https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-04#section-3.8 ).

I agree with you, anyway.

[Nat Sakimura]

Open now. Freddi to come up with the consistency check with the OB spec.

[Brian Campbell]

Just reiterating what I said on the call today, which was that in the context of a requests object the iss value is effectively redundant data to the client_id that is already in the requests object JWT.

[Joseph Heenan]

This was discussed on today's call, to summarise the key points:

Nat feels that aud being optional in OIDCC is a bug that should be raised to OIDCC, and the consensus was we should make it mandatory in FAPI.

It wasn't clear why OIDCC has the "or include the OP's Issuer Identifier URL".

Brian mentioned that iss duplicates client_id (and client_id is already mandatory to include in the request object); including the client_id twice in the request object is hence unnecessary and bloats the request object, which is a concern when passing the request object by value as request objects - as we are getting to the point where the approx 2000 character length some implementations impose on URLs is an issue (see https://github.com/openid-certification/oidctest/issues/134 for a long discussion on URL length.)

[Dave Tonge]

I agree with aud being mandatory, but don't think iss should be because of the request object size problem.

[Luke Popplewell]

iss is no longer mandatory under AUS spec due to duplication of client_id. aud is mandatory.

[Joseph Heenan]

As per the discussion on the 6th December call I've raised a bug to OIDCC; https://bitbucket.org/openid/connect/issues/1059/core-makes-aud-in-request-object-optional

[Dave Tonge]

@lukepopp I agree that there is duplication, however I wonder if this will affect interoperability?

It would be good to discuss this.

[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>>