Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: spelling errors


  • ePA will continue to use a controlled vocabulary; turning this into an open value is out of scope. - consensus reached on our very first call
  • Affiliation should not be confused with Entitlement. This working group recognizes that SPs often prefer ePA because it’s a controlled vocabulary and therefor therefore is easier to implement. Entitlement is not a controlled vocabulary and requires more work to be useful, but is likely to be more accurate across a broader scope of IdPs.
    • Some disagreement about Entitlement being more work, especially when compared to the work required to add new values to the controlled vocabulary
    • Entitlement comes from a variety of sources and from several inputs for various purposes; it is not a typical LDAP attribute.
    • Service providers would need to convince hundreds and (possibly) thousands of IdPs to release a consistent set of information in entitlement; that said, the same effort is required to get them to agree to a new ePA value
  • ePA is to define a relationship. ePE is to define what you can do.
    • Need to clarify what the relationship is to - it is the relationship with the issuer  ONLY; that should not imply what access the individual has
      • We have consensus on “ePA is only to define a relationship with an issuer",

      • Suggest that we should be emphasized in the non-normative narrative for ePAePA is to define a relationship. ePE is to define what you can do.

    • ePE is the relationship to the SP

      • Some disagreement; this is not just about a relationship of the user to the SP - it’s about the the relationship of the issuer of the entitlement and the service.

      • ePE cannot be asserted if there is no relationship between the IdP and the SP

  • The purpose of ePA is to define the relationship a user has with an issuer. This group should specify the common relationships that a user might have with their home organization.
    • We are all interested in interoperability. We want to be able to say this person has an affiliation that is understood across SPs. We should not be trying to determine what affiliation means within a campus; only what it means between issuers and services. 
    • The original values were out of campus directory systems. Are there other relationships common to campus directory systems internationally? Or do we need new terms that are not in a directory system?
    • Should we differentiate between the vocabulary for eduPersonScopedAffiliation and Affiliation, given eduPersonScopedAffilliation is more often used internationally? They were originally designed to be the same. 
    • The terminology doesn’t matter if you don’t have a shared definition; part of the original problem of the current definitions is that we do not require a tightly shared definition
  • We will not make backwards backward-incompatible changes to the current ePA vocabulary semantics due to the large existing deployment.
    • No discussion
  • Rather than further dilute this controlled vocabulary, if someone feels there needs to be more here, instead create a whole new attribute. The current affiliation values should be a broad brush. Anything more specific would belong somewhere else.
    • We would still have the challenge of getting people to support the change. 
    • Which is the lower barrier? Some think it is easier to add a new value than to make a new attribute. We definitely can’t impose new definitions on existing values


  • Researcher - note that defining this on campus is not typical; how would they know to populate this affiliation?
  • Contractor
  • Separate Student a bit more (undergraduate vs post graduatepostgraduate; remote vs local; K-12)

What about using different scopes to get into these more tightly defined areas?