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

Tom Jones thomasclinganjones at gmail.com
Mon Jul 30 22:23:01 UTC 2018


An amazing juxtaposition just occurred for me as i listened to Justin
Richer explain why the OAuth 2.0 spec was so deficient (Identiverse),
mostly due to leaving the security to developers.

And then listening to a developer tell me to "just leave the security to
us".

Sorry - the cognitive dissonance is just too high. If you don't want a
security spec, that should be fine. But why should we assume that others
will get this right, or even that  Open Banking will get it right?

I would actually propose that ephemeral sids be banned from FAPI pt 2.

Peace ..tom

On Mon, Jul 30, 2018 at 1:56 PM, Torsten Lodderstedt <
torsten at lodderstedt.net> wrote:

>
> Am 30.07.2018 um 22:14 schrieb Tom Jones <thomasclinganjones at gmail.com>:
>
> FAPI part 2 is to support a read/write protocols for financial accounts
> (et al.) I cannot image the point of an access to write to a user account
> without the SID.
>
>
> With an ephemeral user id?
>
> Please take a look onto the actual APIs FAPI is used to get access to
> (e.g. Open Banking UK). FAPI is used as security profile of OAuth to obtain
> access tokens good to access those APIs. If there is a need for a user id,
> it’s being conveyed in the access token. The client doesn’t need to know it.
>
> If you have some other problem, then don't use FAPI pt 2.
>
>
> Peace ..tom
>
> On Mon, Jul 30, 2018 at 12:29 PM, Torsten Lodderstedt <
> torsten at lodderstedt.net> wrote:
>
>> I agree bur an user id doesn’t help with replay detection. Nonces or
>> other kinds of transaction specific ids do.
>>
>> OAuth/OpenID Connect already have plenty of it: nonce, state,
>>  code_challenge/code_verifier
>>
>> So there is no need to introduce a new one.
>>
>> Am 30.07.2018 um 19:53 schrieb Tom Jones <thomasclinganjones at gmail.com>:
>>
>> It is my strong opinion that any authorization grant must be tied to some
>> sort of identifier. Otherwise attacks, like replay, become possible.
>>
>> thx ..Tom (mobile)
>>
>> On Mon, Jul 30, 2018, 10:06 AM Torsten Lodderstedt <
>> torsten at lodderstedt.net> wrote:
>>
>>> Hi Tom,
>>>
>>> > Am 30.07.2018 um 17:31 schrieb Tom Jones via Openid-specs-fapi <
>>> openid-specs-fapi at lists.openid.net>:
>>> >
>>> > 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.
>>>
>>> That’s exactly the point.
>>>
>>> In my opinion, there is no need to carry a sub in the detached signature
>>> (aka ID Token) if all the RP asks for is authorization to access a payment
>>> or account information API. So implementors decided to use an ephemeral sub
>>> value, I assume to meet privacy regulations and to not be forced to ask the
>>> user for consent to provide the RP with a user id without a real need.
>>>
>>> > The sid can be ephemeral.
>>> > So, what's missing for you now?
>>>
>>> If the same RP now wants to obtain a sub in order to register the user
>>> or log the user in, there is no way to distinguish the two use cases and
>>> the OP cannot provide the RP with a stable sub value.
>>>
>>> My proposal is to let the RP ask for the detached signature using a
>>> dedicated response type, e.g. „signed_code“, and let the openid scope value
>>> control whether the ID Token contains a sub value or not. I think this as
>>> close as one can get to the original OpenID Connect philosophy.
>>>
>>> kind regards,
>>> Torsten.
>>> >
>>> > 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.openi
>>> d.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-t
>>> hat-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
>>> >>
>>> >>
>>> >>
>>> >> 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.
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180730/885d6f62/attachment-0001.html>


More information about the Openid-specs-fapi mailing list