[openid-specs-rande] today's meeting notes

[Roland Hedberg]

> 18 mars 2019 kl. 16:23 skrev Davide Vaghetti <davide.vaghetti at garr.it>:
> 
> Hi,
> 
> some comments below.
> 
> On 15/03/19 12:28, Mischa Salle wrote:
>> Hi,
>> 
>> On Thu, Mar 14, 2019 at 02:03:14PM +0100, Roland Hedberg wrote:
>>> 
>>> 
>>>> 12 mars 2019 kl. 16:54 skrev Nick Roy <nroy at internet2.edu>:
>>>> 
>>>> On 12 Mar 2019, at 7:53, 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 ;-)
>>>>> 
>>>>> 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
>>>> 
>>>> +1
>>> 
>>> So you’re proposing that instead of using a feature described in the standard
>>> you want to use something that is not in the standard at all ?
>>> 
>>> And the reason from not using a feature descibed in the standard was that there was
>>> lack of support ?
>> 
>> I agree that solving the problem of lack of support in the client
>> software for claims request by adding new information in the metadata
>> published by the same client is just moving the problem (and actually
>> solving a subset, unless you talk about client-metadata per protected
>> endpoint).
> 
> Yes. Let me add that in the SAML world the RequestedAttribute in the
> metadata is far from being considered the ideal tool to communicate RP
> needs in terms of attributes (for example not all RPs specify them; RPs
> that support them tend to forget to add or update it; IdPs have a mix of
> dynamic and static rules).
> 
>> If we can solve the problem on a central proxy on the other hand, we
>> might have a chance. Hence my reference to and focus on the AARC BPA.
>> 
> Before going any further, I'd rather try to understand what problem
> we're trying to solve and what are the use cases. Might be a good idea
> to try to have Hans Zandbelt also participate to this discussion. I
> don't know him personally, maybe you Mischa or Roland would like to
> invite him to join the list?

Can do that !

—Roland
The reward for conformity was that everyone liked you except yourself. -Rita Mae Brown, writer (b. 28 Nov 1944)