Community Review in progress!
This document contains DRAFT material intended for discussion and comment by the InCommon participant community. Comments and questions should be sent to the InCommon participants mailing list (participants@incommon.org).
Default Attribute Release Policy
By definition, a default attribute release policy specifies a set of attributes to be released to any SP. To be clear, not all IdPs have such a policy. For example, most (if not all) of the IdPs in the Hide From Discovery Category do not have a default attribute release policy. On the other hand, a discoverable IdP necessarily has a default attribute release policy since it responds to all authentication requests.
What is a discoverable IdP?
A discoverable IdP will be configured such that both of the following are true:
The IdP consumes the metadata of all SPs
The IdP responds to all authentication requests
An IdP that is unable (or unwilling) to do so is advised to self-assert membership in the Hide From Discovery Category.
Like all IdPs, a discoverable IdP has an unspecified attribute release policy governed by local policy constraints, that is, an IdP’s attribute release policy is strictly a local decision. However, an IdP’s ability to successfully interoperate with all SPs is a shared responsibility that leads to an overall positive federated user experience, and so a reasonable default attribute release policy is the first step towards becoming a good federation participant. With the foregoing as a premise, this page discusses the technical and policy aspects of default attribute release.
Crafting a Default Policy
An IdP with a reasonable default attribute release policy will, for some subset of the IdP's user population, release a persistent, non-reassigned identifier to all SPs (including global SPs) without administrative involvement, either automatically or subject to user consent.
A deployer has a wide range of default policies from which to choose. For simplicity, consider the set of name identifiers separate from other user attributes. Note that the lists below are not exhaustive; they are intended to be illustrative only.
Default name identifiers:
SAML2 Transient NameID
SAML2 Persistent NameID (which is equivalent to the
eduPersonTargetedID
attribute)
Default user attributes:
eduPersonUniqueId
eduPersonTargetedID
(which is equivalent to the SAML2 Persistent NameID)eduPersonPrincipalName
It is recommended that every IdP release a persistent, non-reassigned identifier to all SPs for some subset of the IdP's user population:
eduPersonUniqueId
OReduPersonTargetedID
OReduPersonPrincipalName
(if non-reassigned)
Note that the SAML2 Persistent NameID and the eduPersonUniqueId
attribute are non-reassigned by definition. The eduPersonPrincipalName
attribute is permitted to be reassigned but there is data to suggest that as many as 75% of InCommon IdPs assert an eduPersonPrincipalName
that is not reassigned. Even if your deployment of eduPersonPrincipalName
is reassigned, it is better to release it to all SPs than to have no default attribute release policy at all.
Regardless of whether your deployment of eduPersonPrincipalName
is reassigned or not, it is strongly RECOMMENDED that IdPs support the eduPersonUniqueId
attribute. It is believed that the use of eduPersonUniqueId
will increase and eventually overtake eduPersonPrincipalName
as the identifier of choice (but time will tell).
Repurpose Your Non-Reassigned ePPN
eduPersonPrincipalName
is non-reassigned, the values of eduPersonPrincipalName
and eduPersonUniqueId
asserted by your IdP MAY be the same.Note that not all SPs need to receive the same default set of attributes. For example, SPs registered by InCommon might receive one set of attributes while other SPs might receive another. A single default attribute release policy avoids needless complication so consider that first.