[Openid-specs-fapi] a look at CIBA
ralph.bragg at raidiam.com
Tue Jun 19 21:22:15 UTC 2018
Yeah I’ll be attending.
From: 32012603040n behalf of
Sent: Tuesday, June 19, 2018 22:16
To: Dave Tonge; Financial API Working Group List
Cc: Chris Michael
Subject: Re: [Openid-specs-fapi] a look at CIBA
I’m running a workshop all day tomorrow- these calls always seem to clash with my workshops :(
Hoping Ralph can do the call?
Head of Technology
+44 7767 372277
From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Brian Campbell via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
Sent: 19 June 2018 21:53:04
To: Dave Tonge
Cc: Brian Campbell; Openid-specs Fapi
Subject: Re: [Openid-specs-fapi] a look at CIBA
Thanks Dave. I do plan to join the call tomorrow so will talk to you (all) then.
On Tue, Jun 19, 2018 at 1:26 PM, Dave Tonge <dave.tonge at momentumft.co.uk<mailto:dave.tonge at momentumft.co.uk>> wrote:
Thanks Brian, this is really useful.
There are definitely some editorial issues with the current CIBA drafts that need addressing.
We're going to discuss Sarah's proposal on the call tomorrow. As FAPI we want to have a spec (or specs) that support so called "decoupled" flows. When we looked around CIBA was the closest to this kind of flow that we could find.
If you can make the call tomorrow it would be great so we can discuss further.
On Tue, 19 Jun 2018 at 20:54, Brian Campbell via Openid-specs-fapi <openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>> wrote:
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 220.127.116.11 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._______________________________________________
Openid-specs-fapi mailing list
Openid-specs-fapi at lists.openid.net<mailto:Openid-specs-fapi at lists.openid.net>
Moneyhub Financial Technology, 2nd Floor, Whitefriars Business Centre, Lewins Mead, Bristol, BS1 2NT
t: +44 (0)117 280 5120
Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 561538) at fca.org.uk/register<http://fca.org.uk/register>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 © . Moneyhub Financial Technology Limited 2018. DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Momentum Financial Technology Limited or of any other group company.
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.
Please consider the environment before printing this email.
This email is from Open Banking Limited, Company Number 10440081. Our registered and postal address is 2 Thomas More Square, London, E1W 1YN. Any views or opinions are solely those of the author and do not necessarily represent those of Open Banking Limited.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi