[openid-specs-rande] scopes vs. claims (WAS today's meeting notes)

[Mischa Salle]

Hi,

On Tue, Mar 12, 2019 at 02:53:42PM +0100, Davide Vaghetti wrote:
> > - related to the different scopes vs. claims discussions going on
> >   currently:
> >     - scitokens uses very much the scopes approach, see e.g.
> >       https://scitokens.org/technical_docs/Claims
> >       and uses a scope-per-claim to prevent the lack of support for the
> >       optional 'claims request'>     - Hans Zandbelt (I asked him at TIIME about support for the 'claims'
> >       request) is of the opinion that it's better to have the OP decide
> >       which claims to release for which protected endpoint/client
> >       combinatios than to have the client request which claims it wants.
> >       I don't think we can always do this, but it is an interesting
> >       point, in particular in AARC BPA context, where we have an
> >       omniscient proxy. We might be able to prevent a lot of tricky
> >       situations...
> 
> If I understand it well, we're speaking of not having the clients asking
> claims in the authentication request. It sounds quite familiar for
> someone coming from SAML based identity federations ;-)

Indeed. To clarify for the non-SAML people: In SAML you typically get
the set of required attributes from the metadata, not from the request. 

> So, in the context of the AARC BPA I agree that this can work, but in a
> more general context I don't see how it can scale. One option that
> easily come to mind is go in the same direction we've followed for SAML:
> rely on metadata to express required claims. In that case it would make
> sense to have both the userinfo endpoint and the id_token claims

Except that you need metadata for each combination client/protected
resource, and that really doesn't scale IMHO.
The typical scenarios that came up in the context of scitokens were
things like
    "I like READ access to directory X and WRITE access to directory Y"
Requesting those type of things in scopes is a mess, and for that the
claims request is much more convenient, since you can ask both claim and
value but if there is very little support then that doesn't help.

The question is how to best map that onto the standard OAuth2 scenarios?
Example scenario: a user wants to access via a webportal (=OAuth2
client) a storage server (=protected resource) to which he/she has
access based on e.g. VO membership.
That's different from the standard 'social' scenarios where the user
grants access to socialprovider X to access its profile at
socialprovider Y, since there is an extra authorization decision to be
made (is user entitled based on VO membership). How to implement that
best probably depends on where the AuthZ decision is to be made,
centrally or at the end-services.

Cheers,
Mischa

-- 
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/x-pkcs7-signature
Size: 3402 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190312/de9e2a12/attachment-0001.bin>