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

Tom Jones thomasclinganjones at gmail.com
Mon Jul 30 17:53:23 UTC 2018


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


More information about the Openid-specs-fapi mailing list