The Pseudonymous Authorization Entity Category can be found on the REFEDS website and text from the website should be used as the authoritative source: https://refeds.org/category/pseudonymous.
By asserting participation in an Entity Category, a service provider (SP) is signaling to identity providers its minimally requited user attribute bundle to successfully grant the user access. Particularly when publishing the SP’s SAML metadata in a federation, each unique SP SAML entity SHOULD assert at most one Entity Category. For example, an SP entity asserting Authorization Only category SHOULD NOT simultaneously assert the Pseudonymous Authorization category. Doing so sends conflicting messages.
If a service needs to accommodate different resource access schemes due to contractual differences, the configuration SHOULD be handled in one of the following ways:
An Identity Provider (IdP) SHOULD simultaneously support all Entity Categories.
To properly support the Pseudonymous Authorization category, in addition to releasing those attributes permitted by the Pseudonymous Authorization category, an Identity Provider (IdP) MUST take care to block any user attribute not permitted by the Pseudonymous Authorization category from being released to an SP asserting this category unless bilateral arrangements are in place.
Most of the attributes permitted in the Pseudonymous Authorization category are multi-valued attributes. When configuring release, an IdP SHOULD only release values applicable to the SP the user is accessing. Further, configuring attribute release may require an underlying contract between the IdP organization and the SP organization. To accommodate these nuances, an IdP may adopt one of the following configuration strategies:
The following example illustrates a possible Pseudonymous Authorization category template for the Shibboleth Identity Provider’s attribute filter policy (attribute-filter.xml). This template permits the release of attributes defined in this category to the named SP entity while explicitly blocks other user attribute released by default from being released:
<AttributeFilterPolicy id="refedsPseudonymousCategoryTemplate"> <PolicyRequirementRule xsi:type="Requester" value="https://sp.example.org"/> <!-- In this example, the IdP by default releases email. This configuration overrides those defaults and blocks their release. --> <AttributeRule attributeID="mail"> <DenyValueRule xsi:type="ANY"/> </AttributeRule> <!-- In this example, the IdP by default releases email. This configuration overrides those defaults and blocks their release. --> <AttributeRule attributeID="mail"> <DenyValueRule xsi:type="ANY"/> </AttributeRule> <!-- Release attributes defined in the Pseudonymous Authorization category --> <AttributeRule attributeID="samlPairwiseID"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="eduPersonScopedAffiliation"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="eduPersonOrgDN"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <!-- Release entitlement values defined by MACE-DIR as well as those specific to example.org’s demo service --> <AttributeRule attributeID="eduPersonEntitlement"> <PermitValueRule xsi:type="OR"> <Rule xsi:type="ValueRegex" regex="^urn:mace:example.org:demoservice:.*$" /> <Rule xsi:type="ValueRegex" regex="^urn:mace:dir:entitlement:.*$" /> </PermitValueRule> </AttributeRule> </AttributeFilterPolicy>
This section documents various pseudonymous, targeted identifiers that are still in common use today. While we encourage organizations to transition away from these as much as possible, we recognize they may still need to be used for the purposes of sharing a pseudonymous identifier during a federated authentication workflow.
From the eduPerson (202001) specification:
NOTE: eduPersonTargetedID is DEPRECATED and will be marked as obsolete in a future version of this specification. Its equivalent definition in SAML 2.0 has been replaced by a new specification for standard Subject Identifier attributes [https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html], one of which ("urn:oasis:names:tc:SAML:attribute:pairwise-id") is a direct replacement for this identifier with a simpler syntax and safer comparison rules. Existing use of this attribute in SAML 1.1 or SAML 2.0 should be phased out in favor of the new Subject Identifier attributes."
This Attribute is a direct replacement for the urn:oasis:names:tc:SAML:2.0:nameid-format:persistent NameID Format defined in SAML. There are obvious syntactic differences, in a deliberate attempt at simplification. The XML syntax and data "triple" are replaced with a simpler id/scope pair encoded into a string, and the awkward use of a pair of URIs to qualify the value is replaced with a simpler, shorter, and more flexible approach that more easily emulates the email address syntax required by many applications, and decouples identifier scoping from SAML entity naming.