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

[Nick Roy]

On 12 Mar 2019, at 7:53, Davide Vaghetti wrote:

> Hi Mischa,
>
> thanks for the great comments! Some answers below.
>
> On 12/03/19 11:30, Mischa Salle wrote:
>> On Mon, Mar 11, 2019 at 05:59:56PM +0100, Davide Vaghetti wrote:
>>> Hi,
>>>
>>> here are the meeting notes of today's call:
>>>
>>>  https://github.com/daserzw/oidc-edu-wg/blob/master/meeting_notes.md
>>
>> Hi all,
>>
>> a few small remarks (apologies for yesterday, I was multitasking a bit
>> too much, trying to fix a very annoying bug):
>>
>> - probably good to include links to each least the two AARC docs about
>>   groups and capabilities G002 and G027, but probably also the new I047
>>   which was one I was thinking about yesterday but couldn't remember the
>>   number. The PDP probably doesn't have a place yet, the old google doc is
>>   https://docs.google.com/document/d/18Me5b63R7GKb_1gDfYH02l2sXr3mCIg_suPRw86Ye7I/edit#
>>
>
> Thanks, linked and also added voPerson.
>
>> - The proper link for the whitepaper is probably (currently) the PDF
>>   attached to
>>     https://wiki.refeds.org/display/CON/Consultation%3A+SAML2+and+OIDC+Mappings
>>
>
> Yes the gdoc is not ideal, but the PDF is still the consultation one and
> I'm not sure it is still the right reference now that the consultation
> is closed. I've linked both!
>
>> - I think we should keep open for now whether or not we want to register
>>   claims. Let's first come up with the specification, then see if it's
>>   close enough to an RFC (which is the stumbling block for getting them
>>   in the register).
>>
>
> No problem in keeping it open IF you're not suggesting to register the
> whole eduPerson, SCHAC and voPerson schemas on IANA, but I know you
> aren't ;-)
>
>> - 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

Nick


>
>>
>> - +1 indeed for the authority for claims discussion on A/B connect.
>>
>> - The main reason people want to have 'self-contained' tokens instead of
>>   using a userinfo or introspection endpoint is performance.
>
> Oh yes, my bad: the way I summarized the discussion seems to say
> something very different. I've fixed the meeting notes.
>
> THanks!
> Davide
>
>>
>> Cheers,
>> Mischa
>>
>>
>
> -- 
> Davide Vaghetti
> Consortium GARR
> Tel: +390502213158
> Mobile: +393357779542
> Skype: daserzw
>
> -- 
> 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/5c4ed484/attachment.asc>