...
eduPerson is an attribute schema that includes bindings to a Lightweight Directory Access Protocol (LDAP) schema and to SAML. It is designed to include widely-used person and organizational attributes in higher education.
What is the aim of defining eduPerson attributes?
The chief aim is to align practice across organizations around a common set of attributes for information specific to higher education and to the IAM (Identity and Access Management) best practices promulgated by the Internet2 Middleware Initative and its various projects.
What is the relation of eduPerson to inetOrgPerson and other standards?
eduPerson extends and profiles existing schema standards to avoid reinvention while acknowledging that many older schemas lack specificity in certain respects.
How can use of eduPerson attributes protect users' privacy?
...
Are eduPerson attributes intended or actually used (consumed) as LDAP attributes, or as attributes in SAML assertions?
That's a sitecontext-specific question. eduPerson may be used in both contexts (and in future ones). If you have no LDAP applications, then you may not find it useful or necessary to actually store attributes directly in LDAP and it may be simpler to just construct them as needed from within SAML software or in a database. However, if you do have the need or the ability to store them in LDAP, it will generally be easier to produce them in SAML too. The more your IDM infrastructure does, the less your SAML software has to do to compensate.
Are there canonical values of eduPersonAssurance that are or should be recoginzed recognized by service providers?
The values of this attribute are generally specific to a community and there are none defined by the eduPerson specification (just as there are no values defined for eduPersonEntitlement). InCommon, for example, has defined assurance profiles and, more recently, an MFA profile that include values suitable for use with this attribute.
...
If eduPerson directory attributes are multi-valued, can one assume services will be able to properly consume corresponding multi-valued SAML attributes?
Attributes designed for searching, such as givenName, sn, or mail, are often not handled correctly if multiple values are supplied in a federated context. So in general, no, one can't assume that, but it is a good practice to report such bugs when they are identified. In terms of correctness, any multi-valued attributes is expected to be handled in that fashion in any context.
Why does eduPerson include the eduPersonOrcid attribute and not eduPersonResearcherId? Won't this lead to new attributes for every kind of identifier?
...
The eduPersonTargetedID is an unusual attribute that does not map easily to an LDAP representation in the way that every other attribute in the schema does. Because its value is intended to be different for every "client application", it cannot easily be maintained in a typical LDAP directory and is not expected to be. That indeed makes it unusual.
...