aud should be mandatory in requests objects

Issue #190 closed
Joseph Heenan created an issue

As I interpret the specs ( ) 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.

Comments (14)

  1. 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

  2. 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.

  3. 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.

  4. 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 for a long discussion on URL length.)

  5. Dave Tonge

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

  6. Luke Popplewell

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

  7. Dave Tonge

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

    It would be good to discuss this.

  8. 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 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 Approved-by: Dave Tonge

    → <<cset be897f6c48de>>

  9. Log in to comment