[openid-specs-rande] Torsten's nice blog / claims request / scopes
Torsten Lodderstedt
torsten at lodderstedt.net
Mon Jun 3 11:44:31 UTC 2019
Hi Mischa,
> On 3. Jun 2019, at 13:40, Mischa Salle <msalle at nikhef.nl> wrote:
>
> Hi Torsten, others,
>
> On Thu, May 30, 2019 at 04:15:27PM +0200, Torsten Lodderstedt wrote:
>> Hi all,
>>
>> sorry for joining the discussion late, but I was a bit busy.
>>
>> I’m happy you like my article :-)
>>
>> The claims parameter is great for requesting user info/id token
>> content in an OpenID Connect authentication request.
>>
>> If I understand your use cases correctly, you are after a way to
>> represent requested permissions in an OAuth authorization request,
>> e.g. an app wants “read" and “write" access to "/foo/subdir” on behalf
>> of the user.
>
> It's indeed (mostly) OAuth2 flows, and presumably mostly using JWTs as
> access tokens. For those latter ones, a claims request doesn't work
> really, since there would (probably) be neither id_token nor userinfo.
>
>> I think a generic structured scope would fit better in this case.
>>
>> Based on my proposal in the article, such a scope could look like this:
>>
>> "structured_scope":{
>> "storage_access":{
>> "resource":"/foo/subdir",
>> "actions":[read, write]
>> }
>> }
>>
>> What do you think?
>
> I agree a structured_scope would be more suitable since it allows more
> structure and flexibility. A claims request would typically request a
> claim with a value, not something like storage_access with two different
> key/value pairs. But the advantage is that is already there, and even
> though the support is not everywhere (which was the motivation for
> looking at scopes-per-claim), it's still part of the core OIDC spec.
Well, it’s there with a well-defined syntax and semantics for requesting claims in id tokens and user info responses.
If you go beyond those use cases, the difference between a new mechanism and the existing mechanism goes down to zero since existing implementations at most support what is defined in the OIDC spec.
best regards,
Torsten.
>
> Best wishes,
> Mischa
>
>
>>
>> I envision to use JSON scheme in the individual scope sub-elements to
>> make it structurally robust while being generic enough to cover all
>> kinds of scope data.
>>
>> best regards,
>> Torsten.
>>
>>> On 27. May 2019, at 09:28, Hannah Short <hannah.short08 at gmail.com> wrote:
>>>
>>> Joining a little late...
>>> why not implement something that's already in the spec and in a way that is
>>> much more scalable
>>> I think this makes a lot of sense. Rather than rolling our own thing and pushing for adoption, referring to the standard and encouraging people to implement it seems a much better solution.
>>>
>>>
>>> On Mon, 20 May 2019 at 20:54, Mischa Salle <msalle at nikhef.nl> wrote:
>>> On Mon, May 20, 2019 at 08:49:39PM +0200, Roland Hedberg wrote:
>>>> Hi Mischa,
>>>>
>>>> I think that why the discuss started on not relying on using the
>>>> claims parameter was that some implementations (most notably
>>>> PingFederate) didn’t support it.
>>>>
>>>> Now, it turns out that we are not the only community that are looking
>>>> at claims to solve a problem.
>>>> Which will hopefully make implementers take note and actually support it.
>>> which would indeed be great.
>>>
>>> My point however was even stronger. In order to support the scenarios
>>> such as https://scitokens.org/technical_docs/Claims#scitokens-scopes
>>> driven by e.g. WLCG, people will have to implement new things, so why
>>> not implement something that's already in the spec and in a way that is
>>> much more scalable (since you can easily request claim/claimvalue
>>> pairs)?
>>>
>>>> Using scope to solve the dataminimalization problem has always been a kludge.
>>> I fully agree...
>>>
>>> Best wishes,
>>> Mischa
>>>
>>>>
>>>>> On 20 May 2019, at 20:39, Mischa Salle <msalle at nikhef.nl> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> after reading Torsten's very nice blogpost [1], and Nat Sakimura's
>>>>> answer [2], (thanks to Jim Basney for pointing it out on the
>>>>> discuss at scitokens.org mailing list [3]) I started wondering why we
>>>>> actually are not using the claims request [4].
>>>>> The reason we started using 'scopes per claim' is because of a lack of
>>>>> support for the 'claims parameter', which is optional in the spec,
>>>>> unlike the 'scope' parameter which is always supported. But now we've
>>>>> gotten to the point where we need to put structure in the scopes, things
>>>>> like "read:/foo" and the like, but using that would *also* require
>>>>> support for non-standard things in client- and server software...?
>>>>> So, am I missing something or have we just made a nice circle?
>>>>>
>>>>> Best wishes,
>>>>> Mischa
>>>>>
>>>>>
>>>>> [1] https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>>>> [2] https://nat.sakimura.org/2019/05/12/comments-back-to-transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-by-torsten/
>>>>> [3] https://groups.google.com/a/scitokens.org/forum/#!topic/discuss/bpshiUuqRtg
>>>>> [4] https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
>>>>>
>>>>> --
>>>>> Nikhef Room H155
>>>>> Science Park 105 Tel. +31-20-592 5102
>>>>> 1098 XG Amsterdam Fax +31-20-592 5155
>>>>> The Netherlands Email msalle at nikhef.nl
>>>>> __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
>>>>> --
>>>>> openid-specs-rande mailing list
>>>>> openid-specs-rande at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-rande
>>>>
>>>> — Roland
>>>> Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963)
>>>>
>>>
>>> --
>>> Nikhef Room H155
>>> Science Park 105 Tel. +31-20-592 5102
>>> 1098 XG Amsterdam Fax +31-20-592 5155
>>> The Netherlands Email msalle at nikhef.nl
>>> __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
>>> --
>>> openid-specs-rande mailing list
>>> openid-specs-rande at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-rande
>>> --
>>> openid-specs-rande mailing list
>>> openid-specs-rande at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-rande
>>
>
>
>
> --
> Nikhef Room H155
> Science Park 105 Tel. +31-20-592 5102
> 1098 XG Amsterdam Fax +31-20-592 5155
> The Netherlands Email msalle at nikhef.nl
> __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3923 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190603/649f5d61/attachment.p7s>
More information about the openid-specs-rande
mailing list