CIBA new synchronous flow

[Pablo Guijarro]

In the current CIBA draft, the flow is assumed to be always asynchronous, due to the user interaction required. However, that interaction might not always be needed:

• The OP could rely on the authentication and consent already captured by a trusted RP via out-of-band mechanisms.
• The OP could decide that it is no required to get explicit user approval to grant access to a specific resource, in accordance with the regulations it abides by and its own access policies.

In those cases, user interaction would not be required, but it would still be good to have an access token per user, as CIBA provides, because that allows the subsequent revocation of a token upon user request, for example.

And, in those cases, the asynchronous flow is not efficient, and might even cause race conditions in notification mode: the notification might reach the RP before the response to the authorize request.

So it seems that a new synchronous flow would be the best approach when the OP does not require interaction with the user. It would be a kind of shortcut to provide the final result already in the response to the authentication request (bc-authorize endpoint).

[Pablo Guijarro]

A possible way to implement this would be to follow a similar approach to the one described in the OIDC Asynchronous JWT Assertion Grant.

Basically, in any of the the two modes (polling and notification), there would be the possibility to end the flow in a synchronous way, including the final result (access token + id token of the user the access token is tied to) in the response to the authentication request (bc-authorize endpoint). Otherwise, the regular asynchronous flow would follow.

The option to use the synchronous flow would be a policy configured in the OP and restricted to a set of scopes per RP, as a result of an out-of-band agreement between the two.

An RP expecting to receive synchronous responses to some or all of the authentication requests issued to an OP, would need to check the authentication response to see whether subsequent requests are required to get the final result or not. The logic could be based on the status code of the response, the fields included in its body or, preferibly, both:

• If the authentication response is a 200 OK and it contains the "auth_req_id" field, then the asynchronous flow is being followed and either polling or notification will be required to get the final result.
• If the authentication response is a 201 Created (any better option?) and it contains the "access_token" and "id_token" fields, then the synchronous flow has been followed and that is the final result.

In the synchronous flow, the amr field within the id_token would probably make no sense, so it would not be included (it is an optional field in OIDC). Alternatively, a specific amr value could be defined for this kind of "implicit" authentication.

Also, for the OP to be able to generate pairwise identifiers in the synchronous flow, the RP would need to use the jwks_uri (provided at registration time) in the request to the bc_authorize endpoint, by using any of these two options:

• mutual TLS
• private_key_jwt method for client authentication

This mechanism to get pairwise identifiers would be analogous to the one just defined in the CIBA spec for the asynchronous flow when using the polling mode, just changing the endpoints.

[Gonzalo Fernández]

The id_token should not be returned as no user authentication has taken place.

[John Bradley]

If the RP has a relationship with the MNO and can ask for attributes without consent then using the JWT assertion flow would be best so that it is not confused with authentication.

I don't think that optimizing CIBA for the case when consent

The other issue is a concern about RP confusing return of attributes with authentication.

CIBA is targeted at authentication of the user over another access channel. It seems like we are starting to bleed over into using it for a more OAuth use case without authentication.

I think we may need to look more closely on how the RP would differentiate the two and how the user is going to understand the difference.

[Brian Campbell]

As John mentioned, the JWT assertion grant from RFC 7523 would be probably be more appropriate for cases where consent is implied or previously obtained. IMHO the use of CIBA should always involve some explicit user interaction. While it could be used without user interaction, it shouldn't have an optimization for the case that adds complexity.

[Pablo Guijarro]

Alright, I agree.

[Pablo Guijarro]

Proposal dismissed due to better suited alternatives identified.