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

Tom Jones thomasclinganjones at gmail.com
Mon Jul 30 20:14:07 UTC 2018


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.
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.
>> 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
>> >>
>> >>
>> >>
>> >> 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/d2c7292c/attachment.html>


More information about the Openid-specs-fapi mailing list