[Openid-specs-fapi] FAPI Profile and openid scope value

Dave Tonge dave.tonge at momentumft.co.uk
Wed Aug 1 04:44:26 UTC 2018


Hi Nat & Torsten

Nat - I agree with you that in a banking context it is useful for the RP
(TPP) to know that the OP (Bank) has done KYC / AML. However I think
Torsten is right that the `sub` claim in OpenBanking isn't being used for
this. At the moment the banks are simply putting in the consent / intent id
into the field. Some of the OpenBanking use cases coming up involve:
 - multiple payments being authorised in a single authorisation
 - multiple parties authorising a single payment
Both these concepts have the potential to further separate the `sub` claim
from an actual user.

Torsten is right that FAPI is an OAuth 2 profile and not an OpenID Connect
profile. From an implementation point of view FAPI part 2 requires OpenID
Connect because of its use of id tokens and request objects. However when
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16 is published we are
likely to update references for request object to point at that instead. I
quite like the idea of a new response type that allows implementers to have
detached JWT signatures but without requiring all of OIDC. However surely
the use case for that would be places where implementers don't want OIDC. I
don't think it would make sense for a client to sometimes request a
response type of `signed_code` and sometimes request a response type of
`code id_token`, as Nat says that seems to be conflating things.

If an OP and RP both support OIDC then as Nat suggests it is surely better
to use the claims or scope values to indicate  that the RP would like
access to the users real identity. As Joseph mentions the end-user would
need to consent to that identity being revealed to the RP and therefore
claims / scope is the best place to convey that request for access to the
long-lived identifier.

> Can you please elaborate on the functions it is used for? (openid scope)

This is a good question and I will need help from vendors / other
implementers to answer. I've definitely heard it mentioned that the
`openid` scope turns on stricter validation, but I don't have a specific
example - @Ralph Bragg <ralph.bragg at raidiam.com> @Joseph Heenan
<joseph at authlete.com>  can you help?

> Did any of the implementations support ephemeral sub values before this
was required by the CMA9 banks?

Again I'm not sure, @Nat Sakimura <sakimura at gmail.com>  @Ralph Bragg
<ralph.bragg at raidiam.com>  do you know?

Thanks

Dave



On Wed, 1 Aug 2018 at 04:04, Nat Sakimura via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Torsten,
>
> You seem to be conflating several things.
>
> 1. scope value "openid" and response type "id_token"
> ---------------------------------------------------------------------------
> The "openid" scope specifically asks the Authorization Server to return
> ID Token. It does not dictate from where.
>
> "id_token" in the response type asks the ID Token to be also returned
> from the Authorization Endpoint.
> "id_token" without "openid" scope is pretty much meaningless.
>
> What goes into ID Token is dictated by claims parameter. There are a
> convenient shorthand for them as a scope parameter, e.g., email,
> profile, etc.
>
> 2. Security and legal reason
> -----------------------------------------
> There are several reasons for using ID Token in the authorization
> response.
>
> a) To find out the tampering -- as a detached signature;
> b) To provide an evidence that the authorization server minted the
> response;
> c) To find out the veracity of the authentication event that happened
> before authorization;
>
> Among them, a) is purely security but b) and c) are legal as well.
>
> In the Open Banking context, the AML requirements also fall to the TPP.
> TPP needs to ascertain that the person who is sending money is
> adequately KYCed and does not fall into the restricted category. It does
> not need to know the permanent identifier of the person but he needs to
> have an evidence that the subject was under the scrutiny. This is the
> concept that we sometimes refer to as partial anonymity. It is a form of
> anonymous entity authentication. It is not the message/transaction
> authentication. Thus, having `sub` even if it is ephemeral (from the
> point of view of the TPP) is very important.
>
> Best,
>
> ---
> Nat Sakimura
> Research Fellow, Nomura Research Institute
> Chairman of the Board, OpenID Foundation
>
> On 2018-08-01 02:24, tom jones via Openid-specs-fapi wrote:
> > I think you mis-understand OpenID connect. The SID is not the user’s
> > true identity. It is just an handle that is used among the user,
> > client and OP.
> >
> > If I am not myself misunderstanding Thorsten’s point – the Open
> > Banking “client” (of no one in particular) is asking to access the
> > banks’ private data base on its own behalf and there is no user
> > defined at the point of initial access to the api. At some later point
> > users are involved, but that is outside the scope of the access to the
> > api.
> >
> > If that is true, I believe that the pt2 spec needs to be altered to
> > specifically state that OpenID Connect is not required. Then you do
> > not need the openid scope. And my interest the pt2 also goes away.
> >
> > thx ..tom
> >
> > FROM: Joseph Heenan
> > SENT: Tuesday, July 31, 2018 10:10 AM
> > TO: thomasclinganjones at gmail.com
> > CC: Financial API Working Group List; Dave Tonge; Torsten Lodderstedt;
> > Justin Richer
> > SUBJECT: Re: [Openid-specs-fapi] FAPI Profile and openid scope value
> >
> > Yes, exactly.
> >
> > FAPI part 2 is I believe intended to a financial-grade mechanism for
> > getting access to a resource (ie. being able to performa a write
> > operation to a bank account).
> >
> > Whilst we're within an openid working group, I don't think there's any
> > necessity that this mechanism has to reveal the user's true identity
> > to the RP (it may, but it may not). The seems to me entirely
> > compatible with legal principles like the EU GDPR where the user's
> > identity should only be revealed to the RP if the RP has a good reason
> > to know it and the user has consented to share their identity (as well
> > as secure access to the resource) with the RP.
> >
> > The question on the table is how the RP should indicate to the OP that
> > not only does it want a "financial grade write" level of security but
> > it also (in this case) needs the user's identity. The solution is far
> > from clear, but I can certainly see that a new scope value meaning "I
> > need the user's real identity" could make sense.
> >
> > Joseph
> >
> >> On 1 Aug 2018, at 01:31, <thomasclinganjones at gmail.com>
> >> <thomasclinganjones at gmail.com> wrote:
> >>
> >> Let me get this straight – you are asking the OpenID foundation
> >> for a specification which is specifically designed not to have an
> >> open ID?
> >>
> >> thx ..tom
> >>
> >> FROM: Torsten Lodderstedt via Openid-specs-fapi
> >> SENT: Tuesday, July 31, 2018 9:08 AM
> >> TO: Dave Tonge
> >> CC: Torsten Lodderstedt; Openid-specs Fapi; Joseph Heenan; Justin
> >> Richer
> >> SUBJECT: Re: [Openid-specs-fapi] FAPI Profile and openid scope
> >> value
> >>
> >> Dave,
> >>
> >>> Am 31.07.2018 um 10:54 schrieb Dave Tonge
> >> <dave.tonge at momentumft.co.uk>:
> >>
> >>>
> >>
> >>> In the current OpenBanking specs the sub field can be used either
> >> for an ephemeral id or for a long lived user identifier:
> >>
> >>>
> >>
> >>> <Screen Shot 2018-07-31 at 10.37.28.png>
> >>
> >>>
> >>
> >>>
> >>
> >
> https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2
> >> [1]
> >>
> >>>
> >>
> >>> There is also a custom claim returned in the id_token:
> >>
> >>> <Screen Shot 2018-07-31 at 10.38.31.png>
> >>
> >>>
> >>
> >>> This isn't an ideal situation as apart from out-of-band
> >> mechanisms, the only way an RP can know if they are receiving a
> >> long-lived
> >>
> >>> identifier is the value in the `sub` field is different from the
> >> value in the `openbanking_intent_id` field.
> >>
> >>>
> >>
> >>> However if an OP omitted the `sub` field entirely, this will break
> >> many OIDC implementations as OIDC states that the `sub` field is
> >> required.
> >>
> >> That’s exactly the point. The OpenBanking Use Cases (from a
> >> function perspective) do not require a „sub" because they are
> >> about authorization for API access not identity
> >> federation/providing. As far as I understand, OpenID Connect with
> >> hybrid flow was used as a foundation of FAPI part 2 because the ID
> >> token in the front channel could be used as detached signature. I
> >> understand the rationale, but the consequence is the authorization
> >> protocol suddenly requires an user id (sub in this case). I assume
> >> the hope was banks would use the opportunity and implement id
> >> federation as part of their PSD2 implementation. They didn’t (at
> >> least in the UK) and return ephemeral sub values instead. The
> >> recommendation for "Non Identity Service Providers" even shows the
> >> "sub" value does not really add any data to the equation. It’s
> >> just there to fulfill the structural protocol requirements.
> >>
> >> That’s why I propose to achieve the same behavior by using a new
> >> response type „signed_code“. It would request the AS to produce
> >> a signed JWT response, much like the ID Token in the OpenID Connect
> >> front channel case but without a "sub“. So vendors (hopefully)
> >> wouldn’t have a hard time to implement it and it would free the
> >> „openid" scope value (again) to determine whether the client wants
> >> a sub and other identity data or not.
> >>
> >> This would allow service providers to offer both use cases, API
> >> authorization (w/o sub) and identity federation (w/ sub), to the
> >> same client_id, simply because the client could turn on identity
> >> federation using the scope "openid".
> >>
> >>>
> >>
> >>> Torsten, you stated that:
> >>
> >>>
> >>
> >>>> in my opinion, the „openid" scope value was designed to
> >> exactly address the use case of providing the client with an user id
> >> (and further user claims).
> >>
> >>>> That’s why further claims can be requested via additional
> >> scope values and the claims parameter if the „openid" scope is
> >> present.
> >>
> >>>
> >>
> >>> I agree that this was the original purpose of the `openid` scope
> >> value, but the situation at many vendors is that it is used for more
> >> than that.
> >>
> >> Can you please elaborate on the functions it is used for? Did any of
> >> the implementations support ephemeral sub values before this was
> >> required by the CMA9 banks?
> >>
> >>>
> >>
> >>> I wonder if we can get input from some vendors on this? (Joseph,
> >> Brian, Vladimir?)
> >>
> >>>
> >>
> >> That would be great!
> >>
> >> kind regards,
> >>
> >> Torsten.
> >>
> >>> Thanks
> >>
> >>>
> >>
> >>> Dave
> >>
> >>>
> >>
> >>>
> >>
> >>>
> >>
> >>> On Tue, 31 Jul 2018 at 08:47, Torsten Lodderstedt via
> >> Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> >>
> >>> Is any of the Open Banking Banks using the sub that way? I‘m
> >> asking because there are several process and transaction ids
> >> involved, which can be used for tracking purposes. I don‘t see a
> >> real benefit in using the sub claim for that purpose. But it makes
> >> combining authorization use cases (such as payment initiation) and
> >> authentication use cases with a single client_id impossible.
> >> That’s a serious limitation.
> >>
> >>>
> >>
> >>> Moreover, the authentication policy in authorization scenarios is
> >> up to the AS. I don’t see why the client should control as it is
> >> the AS who needs to ensure proper protection of the users resources.
> >>
> >>>
> >>
> >>> Am 31.07.2018 um 05:28 schrieb n-sakimura via Openid-specs-fapi
> >> <openid-specs-fapi at lists.openid.net>:
> >>
> >>>
> >>
> >>>> A clarification: I suppose you mean `sub` by `sid`. Is that
> >> right?
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> To me, `sub` seems to be perfectly adequate, especially if you
> >> want to be sure that the subject, while ‘anonymous’ to the
> >> client, is still KYCed and authenticated for the session. The `acr`
> >> values are linked to this `sub` value, not to `nonce` or something,
> >> as it is linked to the identity proofing. Additionally, if something
> >> happens, the Bank, as a designated opener, can open the transaction
> >> and track the subject.
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Best,
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Nat Sakimura
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> From: Openid-specs-fapi
> >> <openid-specs-fapi-bounces at lists.openid.net> On Behalf Of Tom Jones
> >> via Openid-specs-fapi
> >>
> >>>> Sent: Tuesday, July 31, 2018 12:31 AM
> >>
> >>>> To: Financial API Working Group List
> >> <openid-specs-fapi at lists.openid.net>
> >>
> >>>> Cc: Tom Jones <thomasclinganjones at gmail.com>
> >>
> >>>> Subject: Re: [Openid-specs-fapi] FAPI Profile and openid scope
> >> value
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> perhaps you can describe why the current spec fails to meet you
> >> needs.
> >>
> >>>>
> >>
> >>>> The FAPI read write #2 profile seems to require openid consent
> >> which seems to require the sid.
> >>
> >>>>
> >>
> >>>> The sid can be ephemeral.
> >>
> >>>>
> >>
> >>>> So, what's missing for you now?
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Peace ..tom
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> On Mon, Jul 30, 2018 at 12:02 AM, Torsten Lodderstedt via
> >> Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> >>
> >>>>
> >>
> >>>> Hi,
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> OpenID Connect already has the mechanics to request and attest
> >> LOA for authentication (acr_values, acr claim). I think identity
> >> proofing requires other mechanisms that allow to complement the
> >> particular user claims (e.g. proofing for email works different and
> >> has other metadata than name).
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> kind regards,
> >>
> >>>>
> >>
> >>>> Torsten.
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> PS: what is the relation of this topic to the initial topic of
> >> the thread?
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Am 29.07.2018 um 21:49 schrieb Ralph Bragg via Openid-specs-fapi
> >> <openid-specs-fapi at lists.openid.net>:
> >>
> >>>>
> >>
> >>>> Tom,
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Could this not be conveyed by a claim instead of a scope? i.e I
> >> require LoA or Vector of trust to meet a certain level for the user.
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> RB
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> From: Openid-specs-fapi
> >> <openid-specs-fapi-bounces at lists.openid.net> on behalf of Tom Jones
> >> via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
> >>
> >>>> Reply-To: Financial API Working Group List
> >> <openid-specs-fapi at lists.openid.net>
> >>
> >>>> Date: Sunday, 29 July 2018 at 20:28
> >>
> >>>> To: Financial API Working Group List
> >> <openid-specs-fapi at lists.openid.net>
> >>
> >>>> Cc: Tom Jones <thomasclinganjones at gmail.com>
> >>
> >>>> Subject: Re: [Openid-specs-fapi] FAPI Profile and openid scope
> >> value
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> why would the needs of the rp impact the open id provider?
> >>
> >>>>
> >>
> >>>> I can think of one reason that has been defined, that of
> >> assurance.
> >>
> >>>>
> >>
> >>>> The RP may require a certain level of assurance, vis a vis the
> >> NIST sp 800-63 (either v2 or v3)
> >>
> >>>>
> >>
> >>>> I would recommending a scope for assurance.
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Peace ..tom
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> On Sat, Jul 28, 2018 at 10:36 PM, Dave Tonge via
> >> Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> >>
> >>>>
> >>
> >>>> Hi Torsten
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> We have an issue open to make it more explicit about the `openid`
> >> scope value:
> >>
> >>>>
> >>
> >>>>
> >>
> >
> https://bitbucket.org/openid/fapi/issues/149/make-it-clear-that-the-entire-flow-is-oidc
> >> [2]
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Your use-case is definitely valid and we've heard it a few times
> >> and definitely need a solution.
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> I'm hesitant to say that the hybrid flow should be able to be
> >> implemented without the `openid` scope value. My understanding is
> >> that many implementations of authorisation servers use the presence
> >> of `openid` in the scope to turn on all the OIDC related features
> >> such as: id tokens, hybrid flow, request object, claims parameter,
> >> stricter processing rules, etc.
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Wouldn't it be better to use another `scope` value for the RP to
> >> indicate that it wants a long-lived end-user identifier (and
> >> possibly other claims), rather than an "ephemeral subject
> >> identifier". From a spec perspective using a scope value of `openid`
> >> doesn't' guarantee the RP that they will receive back a long-lived
> >> user identifier.
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> I agree with you that it would be better to handle both use cases
> >> from a single client.
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> What do you think about using another scope value?
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> Dave
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> On Sat, 28 Jul 2018 at 13:58, Torsten Lodderstedt via
> >> Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> >>
> >>>>
> >>
> >>>> Hi all,
> >>
> >>>>
> >>
> >>>> the "Read and Write API Security Profile" mandates the AS to use
> >> response type values "code id_token" or "code id_token token“
> >> meaning an ID Token is provided in any case. In my understanding ID
> >> Token is primarily used to further secure the interaction, e.g. by
> >> providing the client with an iss claim used to detect mix-up.
> >>
> >>>>
> >>
> >>>> Is it possible for the RP to use this functionality without the
> >> „openid" scope value? The reason I’m asking is I would like to
> >> let a RP/client differentiate use cases where it just wants to
> >> obtain an access token for API access but is not interested in the
> >> user id and use cases where the same client (now as RP) wants to
> >> obtain user id and further claims. Using the scope value
> >> „openid“ to differentiate those use cases seams straightforward
> >> to me. Otherwise the RP would need to use two different client ids
> >> with different sub claim policies for the different use cases, which
> >> most likely will cause complexity in the AS/OP's consent handling as
> >> I assume the RP would like to be the same legal entity in both
> >> cases.
> >>
> >>>>
> >>
> >>>> Thoughts?
> >>
> >>>>
> >>
> >>>> kind regards,
> >>
> >>>>
> >>
> >>>> Torsten. _______________________________________________
> >>
> >>>> Openid-specs-fapi mailing list
> >>
> >>>> Openid-specs-fapi at lists.openid.net
> >>
> >>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi [3]
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>>
> >>
> >>>> --
> >>
> >>>>
> >>
> >>>> Dave Tonge
> >>
> >>>>
> >>
> >>>> CTO
> >>
> >>>>
> >
> >
> >
> > Links:
> > ------
> > [1]
> >
> https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2
> > [2]
> >
> https://bitbucket.org/openid/fapi/issues/149/make-it-clear-that-the-entire-flow-is-oidc
> > [3] http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> >
> > _______________________________________________
> > Openid-specs-fapi mailing list
> > Openid-specs-fapi at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180801/5b1781bf/attachment-0001.html>


More information about the Openid-specs-fapi mailing list