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

Tom Jones thomasclinganjones at gmail.com
Sun Jul 29 19:28:04 UTC 2018


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
> [image: Moneyhub Enterprise]
> <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
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180729/eaa9c2f9/attachment-0001.html>


More information about the Openid-specs-fapi mailing list