[Openid-specs-fapi] a look at CIBA

Brian Campbell bcampbell at pingidentity.com
Tue Jun 19 20:53:04 UTC 2018


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>
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.
>
> Thanks
>
> Dave
>
> On Tue, 19 Jun 2018 at 20:54, Brian Campbell via Openid-specs-fapi <
> 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 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.*_______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>
>
>
> --
> Dave Tonge
> CTO
> [image: Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> 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. 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._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180619/6d5cc837/attachment.html>


More information about the Openid-specs-fapi mailing list