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

Dave Tonge dave.tonge at momentumft.co.uk
Tue Jul 31 08:54:28 UTC 2018


In the current OpenBanking specs the sub field can be used either for an
ephemeral id or for a long lived user identifier:

[image: 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

There is also a custom claim returned in the id_token:
[image: 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.

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.

I wonder if we can get input from some vendors on this? (Joseph, Brian,
Vladimir?)

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
>
>
>
> 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
>
>
>
>
> --
>
> *Dave Tonge*
>
> CTO
>
>
> <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
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> *t: +44 (0)117 280 5120
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>*
>
>
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> 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.
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> *Openid-specs-fapi at lists.openid.net*
> *http://lists.openid.net/mailman/listinfo/openid-specs-fapi*
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
>
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> *Openid-specs-fapi at lists.openid.net*
> *http://lists.openid.net/mailman/listinfo/openid-specs-fapi*
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> *Openid-specs-fapi at lists.openid.net*
> *http://lists.openid.net/mailman/listinfo/openid-specs-fapi*
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
>
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180731/857e74ce/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-07-31 at 10.37.28.png
Type: image/png
Size: 125883 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180731/857e74ce/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-07-31 at 10.38.31.png
Type: image/png
Size: 51252 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180731/857e74ce/attachment-0003.png>


More information about the Openid-specs-fapi mailing list