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

[Mischa Salle]

Hi Davide,

On Tue, Mar 12, 2019 at 02:53:42PM +0100, Davide Vaghetti wrote:
> > - 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.
makes sense!

> > - 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!
agreed. Actually I don't know what the current status is? We should ping
Niels or Nicole I guess.

> 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 ;-)
(-;

Although I wonder if we could standardise the conversions
    eduPersonFooBar -> eduperson_foo_bar
    voPersonFooBar  -> voperson_foo_bar
    SchacFooBar	    -> schac_foo_bar

It would be good to make sure that everyone uses the same claim names,
which is more likely to fail than to prevent that the same claim name is
used for different things.
E.g. RAF is still referring to the "multi-valued eduPersonAssurance
claim, as defined in [REFEDS OIDCre]" which actually according to (the
newest verision of) the link should be eduperson_assurance.

> > - 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
I'll start a separate thread on this one...

> > - +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.
Hmm, I actually think I didn't mention this, but should have...
So now we have notes from a meeting as it should have been (-;

    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/3ba7a739/attachment.bin>