[Openid-specs-fapi] a look at CIBA

Brian Campbell bcampbell at pingidentity.com
Tue Jun 19 18:54:08 UTC 2018


On a recent-ish Wednesday bi-weekly FAPI call I was *encouraged* to review
the CIBA stuff. This email is the result of my attempting to do that. I say
attempting because I found the task rather difficult and time consuming to
do. So this 'review' isn't comprehensive (or necessarily coherent or
organized). I tried to touch on what seem like important things. And a few
trivial bits snuck in too.

It's somewhat difficult to know what to review as Financial_API_WD_CIBA.md
references what seems to be the most recent published CIBA draft, which is
dated March 6, 2017. The xml source file in the MODRNA Mercurial repo,
however, has seen a number of commits in the year+ since that time.

It's rather unconventional and awkward for FAPI to try and profile or use a
draft spec from a different WG in a different vertical. It might work okay
if CIBA was a generally applicable and a stable standard but it's still
very much just a draft and has some MODRNA specifics in it.

Isn't this really more of an out-of-band authorization than it is
'backchannel' user authentication? The CIBA name and even use of id tokens
and user authentication don't quite click for me.

I'm no stranger to typos myself so can't be too critical here but the
MODRNA CIBA draft has an unusually large number of typos (misspellings,
missing words, that kind of thing). Most are simple editorial issues but it
leaves the impression that the document hasn't gotten much attention or is
neglected or even abandoned. I gave up trying write down all the editorial
issues but there is one (that I saw anyway) typo that's more than just
editorial n a parameter name where sec 7.3 defines "expires in”,
which, based on convention and the parameter name in the example below, I
assume should be "expires_in".

The format of the Authentication Request isn’t defined sufficiently. 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. I see the idea behind CIBA
wanting to just kinda reuse the OAuth 2.0 Authorization Request in this
back-channel context but I think it 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.

CIBA says the OP "MUST validate the hint provided (login_hint,
login_token_hint or id_token_hint). e.g.: If a signature is provided it
MUST be checked. If a validity date is provided it MUST be checked." For
id_token_hint in particular this is really problematic as an ID Token is
issued for a different context to a different audience and typically with a
shortish validity period. OIDC core kind of touches on the issue by saying
the AS need not be listed as an audience of the ID Token when used as an
id_token_hint value. The id_token_hint from OIDC core isn't the most
clearly defined parameter to begin with and while CIBA defers to OIDC for
it's definition the usage is somewhat different. But potentially more
important to a CIBA flow. As it is, consistent and interoperable treatment
of id_token_hint seems unlikely.

CIBA has a new endpoint sometimes called Backchannel Authentication
Endpoint and sometimes called bc-authorize (also kinda implying that should
be the actual path, which shouldn't be dictated by spec).  A new endpoint
should be introduced/described and define (and register) a new
Authorization Server Metadata parameter for it that allows the AS to
determine the endpoint URI and provide it in metadata. The device flow does
this with its Device Authorization Endpoint   https://tools.ietf.org/html/
draft-ietf-oauth-device-flow-09#section-7.3 which is similar in many
respects to CIBA's new endpoint and is a good pattern to follow. There are
other missing IANA registrations too.

CIBA says to authenticate to the Backchannel Authentication Endpoint using
the authentication method registered for its client_id. But then goes on to
say that the RECOMMENDED authentication method is with an Signed Request
Object. But there is no OAuth client authentication method corresponding to
Signed Request Object. There's no signed request authn to the token
endpoint. The client authn stuff needs to be rationalized.

In one or two places CIBA says that errors from the new endpoint "MUST
return an error response, per Section 3.1.2.6 of [OpenID.Core].” which is
nonsensical because that's a redirect to the client's redirect uri. A
different section of CIBA does define 40x error response codes for the new
endpoint, which is more appropriate. But it contradicts it's own MUST.

Having acr_values be a required parameter of the "Authentication Request"
might work for MODRNA (I don't know) but I don't think makes sense in a
more general cases.

The treatment of refresh tokens seems a bit inconsistent with some text
sounding like an RT will/must always be returned. Other text is more clear
that it's optional, as is the case with other OAuth flows/grants, and how
it should also be throughout CIBA.

Extension grant types are full URIs by definition from RFC6749 but CIBA
intermixes backchannel_request and urn:openid:params:modrna:
grant‑type:backchannel_request.

This email seems entirely too long yet incomplete. And I'm not sure how to
end it. But that's all for now.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180619/7c341911/attachment.html>


More information about the Openid-specs-fapi mailing list