Clarify CIBA Authentication Request format

Issue #67 resolved
Brian Campbell created an issue

Coming to this relatively new and reading CIBA with the perspective of potentially implementing it (due to FAPI profiling CIBA), I feel there's some ambiguity around the format of the Authentication Request (sec 4.1 in the published version and sec 7.1 of the latest from source). The example shows a POST with application/json in the body while the text defers to authorization/authentication request of OAuth/OIDC, which uses application/x-www-form-urlencoded parameters. The text (in the latest source) also says that OpenID Connect Signed Request Object (referencing OIDC §6.3.2) can be used, which could be interpreted to mean form-urlencoded parameters with request=[JWT] or request_uri=[URL to JWT] and also requiring the scope, response_type and client_id parameters to be present as form parameters and that their values match the same named claims in the JWT. OIDC also says that parameters MAY also be passed using the OAuth 2.0 request syntax (regular form parameters) even when a Request Object is used and that both are considered with the values contained in the JWT Request Object superseding those passed using the OAuth 2.0 request syntax. I rather doubt that the intent of CIBA was to bring in all that baggage from OIDC's request object but that's how OIDC defines it and so is a not unreasonable interpretation of the CIBA draft, particularly for someone familiar with Connect or pedantic about reading its details.

I see the idea behind CIBA wanting to just kinda defer to the OAuth 2.0 Authorization Request / OIDC Authentication Request in this back-channel context but those are designed to pass through a user's browser via redirection, which is rather different than direct a client to AS request like CIBA needs. I think basing the CIBA request on the OIDC/OAuth front-channel requests actually causes more issues than it solves. And it'd be more appropriate and straightforward for CIBA to directly define the parameters and format/encoding. The relevant parameters are already defined in the Authentication Request section. The format/encoding just needs to be more clearly stated. From what's there now, I suspect that the intent is to have the request be JSON in the body with the parameters as top level members of that JSON and the content-type would be application/json. That's what the example in the draft has now but the normative text doesn't unambiguously say it. For a 'signed request' the content-type should probably be application/jwt with the body of the request being just the JWT that's payload is the claims that would be the JSON of the actual request parameters. The JWT should probably be required/encouraged to also have an audience and expiration.

Comments (14)

  1. Dave Tonge

    I agree with this. It would be better for requests to either be application/json or application/jwt.

    I agree that there is some baggage with taking the request object, however there are also benefits when it comes to the existing metadata around request object signing.

  2. Brian Campbell reporter

    I'd argue that any metadata (client or server) needed by CIBA for this should be independently defined because it really is an entirely different thing.

  3. Dave Tonge

    I agree - is there consensus on changing this to either be application/json or application/jwt and removing references to request object and OAuth 2.0 request syntax (regular form parameters)?

  4. Brian Campbell reporter

    My sense is that there is rough consensus to allow both application/json or application/jwt (probably need some metadata about it too) as the format. And yes to removing references to request object and OAuth 2.0 request syntax.

  5. Dave Tonge

    We discussed this on the call today and agreed that in order to support the registered client auth methods we need to use: application/x-www-form-urlencoded. There was agreement to specify all of the params required (dependent of the definitions for the authorization request in RFC6749/OIDC). There was also agreement to specify how the params could also be passed in as a JWT as the value for a request param.

  6. Gonzalo Fernández

    As I commented on issue #73 I agree with using client authentication methods, so that I agreed with all about the need to use application/x-www-form-urlencoded. I don't understand what we need to specify for the params to be passed in as a JWT, is not this the Request Object?

  7. Brian Campbell reporter

    It is conceptually similar to the OIDC Request Object in that what would be the form parameters are encoded as claims in the JWT. But it is not the Request Object per se. There's a lot of baggage that comes with the Request Object (some of which is noted in the 1st paragraph of the ticket description) that's really problematic to pull in here.

  8. Log in to comment