European Workshop on Trust & Identity

In cooperation with GeantLogo184x80

Session 18 <Mapping Eduperson to OIDC claims> (14:15/Room K6)

Convener: Jim Basney

Abstract: Mapping EduPerson to OICD claims

Tags: Attributes, OIDC

Notes

Presentation of the attribute values of EduPerson and identifier properties. Discussion on so called "orphans" (that have been created but have no place in the OICD connect place).

  1. 1.Attribute values
  • Explanation of the open document (http://goo.gl/ryIqL3), definition of the terms (given_name, family_name etc.)
  • Discussion of the definition / possibility to define the term "middle_name"
  • Discussion of the definition / possibility to define the term "name" (what it could mean), basically you could put anything there
  • profile: URL with some proper information of the user
  • picture: jpegPhoto, give info about race, gender, religion, typically problematic for IP to release -- (no) good match here (comparison of US, Austria - publishing law, data protection law)
  • website (user is affiliated to), gender, birthdate (nothing in eduperson space either, very sensitive in perspective of data protection)
  • zoneinfo (info about where you live, or time zone)
  • locale (preferred language)
  • address
  • updated_at (doesn't tell about the updated sessions of the user - recent updated, total updated? ; session time out, a lot of possibilities what we could put in there)
  • email
  • email_verified (basically says that in some way between RP and OP there is an agreement of what verified means, in our case we could use this, maybe we could decide to consider an institutional email address to be verified)
  • can be defined in any way we like
  • i.e. university account, institutional email address
  • Address; what exactly to put in? Personal address, office address, institutional address/department address?
  • Phone - home/office - which number?
  • phone verified - proposal: if it was provided by the IDP it is verified


Short Q&A:

  • Single valued? - No, almost all are multi-valued.
  • Phone value? – International.
  • Street name? - depends on the place.
  • Preferred user name? - Greens: mostly in common use, which is good for this case.

  1. 2.Identifier
  • identifier properties / explanation of the table


I’ve assumed that we will not support a scenario, technically we would need a proxy to beach from a to b.

What are the mechanics?

  1. You provide a URL, then you’ll find a list of names etc.

You must be sure that you are giving the same proxy?

Looking at the 4 scenarios that we have, explanation

(table MAPPING SAML -> OICD PUBLIC SUB CLAIM...)

(table MAPPING SAML -> OICD PAIRWISE SUB CLAIM...)

(table MAPPING OICD pairwise sub claim -> SAML: What SAML identifiers can be create from an OICD pain

  1. 2. "orphans" - have been created but have no place in the OICD connect place

Discussion on terms:

  • eduPersonPrimaryAffiliation
  • (organizationName)
  • eduPersonAssurance


Given that number of red ones, which we must have, especially:

  1. eduPersonAffiliation
  2. eduPersonScope
  3. ?? XXX


How to do that?

JSON Web Token (JWT)

OpenID Connect does not specify cardinality, which may limit ability to map OIDC name to eduPerson name if the latter one specifies a single valued attribute.