[Openid-specs-fapi] FAPI Profile and openid scope value
dave.tonge at momentumft.co.uk
Sun Jul 29 05:36:16 UTC 2018
We have an issue open to make it more explicit about the `openid` scope
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,
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
What do you think about using another scope value?
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.
> kind regards,
> Torsten. _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
[image: Moneyhub Enterprise]
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.
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...
More information about the Openid-specs-fapi