[openid-specs-rande] Torsten's nice blog / claims request / scopes
Mischa Salle
msalle at nikhef.nl
Mon Jun 3 11:40:34 UTC 2019
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.
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: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190603/474d8e08/attachment.asc>
More information about the openid-specs-rande
mailing list