[Openid-specs-fapi] OpenBanking CIBA flow / login_hint_token

Brian Campbell bcampbell at pingidentity.com
Wed Jun 19 15:53:24 UTC 2019


Recognizing that there's some uncertainty and differing opinions about how
to convey intent id (and such type things), we've tried to design our CIBA
support such that it could reasonably be set up to handle it being sent as
a parameterized scope value, additional parameter, or claim in a login hint
token JWT.

I think reasonable people could make reasonable arguments for any of them
as the right way to do it. Personally, the parameterized scope value seems
to me to be the most proper approach. So I guess that's my preference.
Followed by additional parameter. Then login hint token. Conceptually login
hint token seems fine but using it then effectively rules out the other
hint types.

On Wed, Jun 19, 2019 at 1:14 AM Dave Tonge <dave.tonge at momentumft.co.uk>
wrote:

> Thanks Ralph
>
> So my idea is that the QR code actually contains a url for the TPP, i.e.
> https://tpp.com/auth?token=some-token-that-carries-the-session-from-the-kiosk-to-a-browser
> There is then a straight forward redirect flow from the TPP to ASPSP and
> back to the TPP on the users device. When the TPP receives the code and
> exchanges it for a token, the TPP server communicates with the TPP kiosk to
> show that payment is complete.
>
> About intent passing, it would be good to hear back from @Brian Campbell
> <bcampbell at pingidentity.com>, @Takahiko Kawasaki <taka at authlete.com> and @Vladimir
> Dzhuvinov <vladimir at connect2id.com> about what their perspective would be
> on how easy it would be to allow a new param to be made available for
> processing,
>
> Dave
>
>
>
> On Wed, 19 Jun 2019 at 09:04, Ralph Bragg <ralph.bragg at raidiam.com> wrote:
>
>> Dave,
>>
>> I’ll sync up with freddi today on this, but my initial comments are that
>> Yes, there’s nothing stopping the Authorization url being generated as a QR
>> code and this flow being a standard redirect however how would the auth
>> code be returned back to the RP? 2.3.3 is designed for a kiosk type
>> situation, you’d need the kiosk to have an input device as well to scan a
>> AS mobile presented QR code to capture the redirect response? Apologies if
>> I’m missing something.
>>
>> My concern with adding additional parameters rather than profiling the
>> token is vendor support. We had the same issue when trying to find a
>> solution that would work with existing vendor capability. If vendors are
>> going to follow the spec as described and allow any attribute to be passed
>> through and made available for process then great... typically I’ve seen
>> that only the named parameter like login_token_hint etc or request_object
>> be available for processing / profiling.
>>
>> I’d prefer to profile the token rather than introduce new parameters.
>>
>> RB
>>
>> ------------------------------
>> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net>
>> on behalf of Dave Tonge via Openid-specs-fapi <
>> openid-specs-fapi at lists.openid.net>
>> *Sent:* Tuesday, June 18, 2019 22:47
>> *To:* Financial API Working Group List
>> *Cc:* Dave Tonge
>> *Subject:* Re: [Openid-specs-fapi] OpenBanking CIBA flow /
>> login_hint_token
>>
>> Hi Chris, Ralph and Joseph
>>
>> So in the base spec we describe the flow where the bank generates a
>> single use identifier (2.3.2 in the Customer Experience Guidelines).
>> I did have language attempting to describe the TPP generated identifier
>> (2.3.3 - the flow described by Joseph), however we dropped the text as we
>> felt it didn't quite fit into CIBA.
>> 2.3.1 and 2.3.4 are also supported out of the box by CIBA.
>>
>> To echo Joseph's point - couldn't the flow described in 2.3.3 be
>> performed using links and a standard redirect flow. i.e. the TPP displays a
>> QR code or link to which the user navigates to on their phone. This starts
>> a standard redirect flow. The only limitation here is that not
>>
>> The separate point of where to pass the intent id is interesting. I'd
>> strongly suggest that OB consider passing it as an extra parameter, rather
>> than including it in to the login_hint_token. In CIBA core we have this
>> phrase: *"An authentication request is composed of the following
>> parameters andMAY contain additional parameters defined by extension or
>> profile:"*
>>
>> Dave
>>
>>
>> On Mon, 17 Jun 2019 at 09:29, Chris Michael via Openid-specs-fapi <
>> openid-specs-fapi at lists.openid.net> wrote:
>>
>>> Thanks @Ralph
>>>
>>>
>>> @Joseph, please can we make sure the spec supports all 4 models/flows as
>>> per
>>> https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines-V1.3.0.pdf
>>>
>>>
>>> While one of these does potentially allow a phishing vector, my
>>> preference would be to allow this but clearly call out the risk, as there
>>> are some use cases where the OP may chose to implement this.
>>>
>>>
>>>
>>> *Chris Michael*
>>>
>>> Head of Technology
>>>
>>>
>>> +44 7767 372277
>>>
>>> http://www.openbanking.org.uk
>>>
>>> 2 Thomas More Square, London E1W 1YN
>>>
>>> Twitter <https://twitter.com/UKOpenBanking> | Facebook
>>> <https://www.facebook.com/UKOpenBanking> | LinkedIn
>>> <https://www.linkedin.com/company/openbanking/>
>>> ------------------------------
>>> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net>
>>> on behalf of Ralph Bragg via Openid-specs-fapi <
>>> openid-specs-fapi at lists.openid.net>
>>> *Sent:* 17 June 2019 07:48
>>> *To:* Financial API Working Group List
>>> *Cc:* Ralph Bragg
>>> *Subject:* Re: [Openid-specs-fapi] OpenBanking CIBA flow /
>>> login_hint_token
>>>
>>> Jospeh, yes sort of. The login hint token is meant to contain a user
>>> identified, either a previously used request/intent ID, a static user ID
>>> that’s pairwise bound to the client or worst case a static ID for the user.
>>>
>>> This would facilitate a push (in the first two cases) and potentially a
>>> phishing Vector in the third.
>>>
>>> If there’s no “hint” then yes, a CIBA flow can be used in the way that
>>> you described however the QR code / thing to convey to the customer just
>>> needs to be a long / nonce intentid, the customer already knows the bank
>>> that they selected and all of the information should have been staged with
>>> the CIBA request this is sufficient to allow a customer to come and claim
>>> the CIBA initiated request. This flow is useful when you’re performing
>>> authN/authZ on two different devices. Mobile to mobile a redirect is much
>>> better.
>>>
>>> ------------------------------
>>> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net>
>>> on behalf of Joseph Heenan via Openid-specs-fapi <
>>> openid-specs-fapi at lists.openid.net>
>>> *Sent:* Monday, June 17, 2019 7:22:55 AM
>>> *To:* Openid-specs-fapi
>>> *Cc:* Joseph Heenan
>>> *Subject:* [Openid-specs-fapi] OpenBanking CIBA flow / login_hint_token
>>>
>>> Hi all,
>>>
>>> On the last call we talked about how the OpenBanking UK spec (
>>> https://openbanking.atlassian.net/wiki/spaces/DZ/pages/1077805207/Read+Write+Data+API+Specification+-+v3.1.2#Read/WriteDataAPISpecification-v3.1.2-CIBA )
>>> uses the login_hint_token in CIBA.
>>>
>>> Dave raised a ticket that’s quite related (
>>> https://bitbucket.org/openid/fapi/issues/228/ciba-and-lodging-intent ).
>>>
>>> I thought it would be useful to people’s comprehension to draw out a
>>> sequence diagram of the OB CIBA flow, in particular the one that uses the
>>> login_hint_token to communicate intent, and uses a QR code to replace the
>>> login_hint_token as a way to identify the user, as I didn’t understand how
>>> this worked when I first read the spec.
>>>
>>> Image of the flow is attached below. Note that it assumes the user has
>>> already setup the bank’s mobile banking app on their phone and linked it to
>>> their account.
>>>
>>> This I believe relates to ‘2.3.3 model C’ on page 40 of
>>> https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines-V1.3.0.pdf -
>>> this has some pictures showing the flow from the viewpoint of the user.
>>>
>>> (I believe this is right, but If anyone from OB can confirm/deny I’m
>>> happy to make corrections. I’ve included both the image and the source
>>> plantuml)
>>>
>>> Thanks
>>>
>>> Joseph
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> @startuml
>>>
>>> title Standard CIBA
>>> autonumber "<b>Step #: "
>>>
>>> box "User Interactions" #LightBlue
>>> participant Relying_Party as RP
>>> participant Authentication_Device as AD
>>> endbox
>>>
>>> box "Bank" #LightGray
>>> participant Authorization_Server as AS
>>> participant Resource_Server as RS
>>> endbox
>>>
>>> RP->RP: User launches process
>>> 'RP->AS: client_credentials grant
>>> 'AS->RP: access_token_client
>>> 'RP->RS: Register intent using access_token_client
>>> 'RS->RP: indent_id
>>> RP->AS: CIBA request
>>> RP<-AS: auth_req_id
>>> AS->AD: request user authenticates
>>> ...wait for user to approve...
>>> AS<-AD: authentication approved
>>> RP<-AS: CIBA ping notification
>>> RP->AS: token request
>>> RP<-AS: access_token
>>> RP->RS: access transaction data using access_token
>>>
>>> autonumber 1
>>> newpage OpenBanking UK version
>>> ' https://openbanking.atlassian.net/wiki/spaces/DZ/pages/1077805207/Read+Write+Data+API+Specification+-+v3.1.2#Read/WriteDataAPISpecification-v3.1.2-CIBA
>>> RP->RP: User launches process
>>> group OB Intent creation
>>> RP->AS: client_credentials grant
>>> AS->RP: access_token_client
>>> RP->RS: Register intent using access_token_client
>>> RS->RP: indent_id
>>> RP->RP: create login_hint_token: \n"IID", intent_id
>>> end
>>> RP->AS: CIBA request: login_hint_token
>>> note right: nothing in here identifies the user
>>> RP<-AS: auth_req_id
>>> group OB link user to request
>>> RP->RP: display QR code containing\nintent_id, auth_req_id
>>> AD->AD: user opens bank's mobile app
>>> RP->AD: user scans QR code
>>> AD<->AS: fetch authorisation details: auth_req_id, intent_id
>>> note right: Only here does AS know what\nuser it is authenticating
>>> end
>>> ...wait for user to approve...
>>> AS<-AD: authentication approved
>>> RP<-AS: CIBA ping notification
>>> RP->AS: token request
>>> RP<-AS: access_token
>>> RP->RS: access transaction data using access_token
>>>
>>> @enduml
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>> This email and any attachments are confidential and are intended for the
>>> above named only. They may also be legally privileged or covered by other
>>> legal rights and rules. Unauthorised dissemination or copying of this email
>>> and any attachments, and any use or disclosure of them, is strictly
>>> prohibited and may be illegal. If you have received them in error, please
>>> delete them and all copies from your system and notify the sender
>>> immediately by return email. You can also view our privacy policy (
>>> https://www.openbanking.org.uk/privacy-policy).
>>> _______________________________________________
>>> 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, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
>> 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 809360) 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 Moneyhub Financial Technology Limited or of any other group
>> company.
>>
>
>
> --
> 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, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
> 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 809360) 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 Moneyhub 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/20190619/9bcc076c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbanking_ciba.png
Type: image/png
Size: 197970 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20190619/9bcc076c/attachment-0001.png>


More information about the Openid-specs-fapi mailing list