Contents

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 by definition.

Minimal Attribute Bundle

Like all IdPs, a discoverable IdP has an unspecified attribute release policy subject to local policy constraints. That said, an IdP easily satisfies the basic requirements of discoverability by releasing the following minimal attribute bundle to all SPs:

Name identifier: SAML2 Transient NameID
User attribute: eduPersonScopedAffiliation

A policy based on the minimal attribute bundle is both easy to implement and privacy preserving. However, since the bundle lacks a persistent identifier, this approach falls short of the basic interoperability requirements of a typical federated SP.

Policy Considerations

As shown in the previous section, it is easy to meet the basic requirements of discoverability—simply release no (identity) attributes by default! Your goal, however, should be true interoperability, which leads to an overall positive federated user experience. A reasonable default attribute release policy is the first step towards becoming truly interoperable.

But what is reasonable? Even though attribute release is a local policy decision, InCommon recommends the following minimal default attribute release policy:

Two aspects of the above definition deserve further discussion. First, the phrase “all SPs” refers to all SPs with metadata published and distributed by InCommon. That includes SPs registered by InCommon as well as SPs registered by other federations. That said, there will no doubt be exceptions to that general rule. For example, an IdP is certainly allowed to blacklist one or more “bad actor” SPs at its discretion.

Second, the phrase “for some subset of the IdP's user population” gives the IdP some flexibility when implementing the policy. In other words, not all users need to have exactly the same experience. For example, students need not be included in your initial focus group, which gives you time to think through the special case of students that fall under FERPA regulations. Such students might require an informed user consent flow to be implemented.

Crafting a Reasonable Default Policy

Each of the following attribute bundles satisfies the above policy.

Attribute Bundle 1

The following bundle includes a persistent, non-reassigned identifier targeted at a specific SP:

Name identifier: SAML2 Persistent NameID
User attribute: eduPersonScopedAffiliation

This bundle improves interoperability (compared to the minimal attribute bundle) while maintaining user privacy. However, a proper deployment of the SAML2 Persistent NameID (which is equivalent to the eduPersonTargetedID user attribute) is a nontrivial endeavor and should not be taken lightly.

Speaking of eduPersonTargetedID, the following bundle is equivalent to the above:

Name identifier: SAML1 Transient NameIdentifier
User attribute #1: eduPersonTargetedID
User attribute #2: eduPersonScopedAffiliation 

This bundle is designed for SPs that request SAML1-format identifiers and attributes. Note that the eduPersonTargetedID attribute provides exactly the same content as the SAML2 Persistent NameID.

The following bundle represents a trade-off between privacy and deployability.

Attribute Bundle 2

The following bundle includes a relatively easy-to-deploy persistent, non-reassigned identifier:

Name identifier: SAML2 Transient NameID
User attribute #1: eduPersonUniqueId
User attribute #2: eduPersonScopedAffiliation

Since eduPersonUniqueId is not targeted (per SP), it lacks the privacy characteristics of the SAML2 Persistent NameID, but since every user has at most one eduPersonUniqueId, it is considerably easier to deploy. For an IdP that doesn’t already assert a persistent, non-reassigned identifier, this bundle represents an attractive middle ground.

The following bundle represents a further trade-off between privacy and deployability.

Attribute Bundle 3

For IdPs that already deploy eduPersonPrincipalName, the following attribute bundle may be simplest:

Name identifier: SAML2 Transient NameID
User attribute #1: eduPersonPrincipalName (if non-reassigned)
User attribute #2: eduPersonScopedAffiliation

Since eduPersonPrincipalName is name-based (and therefore not opaque), it is the least private of all identifiers mentioned so far. However, eduPersonPrincipalName is widely deployed, so for many IdPs, this is the simplest option.

References

• Shibboleth Concepts: NameIdentifiers