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

[Davide Vaghetti]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4136 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20190312/e593c2a4/attachment.p7s>