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

[Nick Roy]

On 12 Mar 2019, at 8:46, Mischa Salle wrote:

> 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.

I see what you’re saying, that makes sense, but it appears that either way we go, we will have a scaling problem.

Nick

>
> 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
>   __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
> -- 
> openid-specs-rande mailing list
> openid-specs-rande at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-rande
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190312/7b240646/attachment.asc>