...

Introduction

This specification defines standardised names and semantics for attributes that may be communicated within a SAML federation. The attribute set is intended as a reference data set of attributes that may be released to Relying Parties.

...

Where applicable, references to external attribute definitions are included, such as corresponding Object Identifiers (OIDs).

SAML Attribute Representation

SAML Attribute Format

When attributes defined in this specification are used, the following requirements apply:

• The <saml:Attribute> element represents an attribute in SAML 2.0.
• The NameFormat attribute MUST have the value urn:oasis:names:tc:SAML:2.0:attrnameformat:uri.
• The Name attribute MUST contain a URI as defined in this specification. Attribute names are expressed as URIs in the form of URLs.
• The FriendlyName attribute is OPTIONAL.
• The data type of the <AttributeValue> element is xs:string using UTF-8 encoding, unless otherwise specified in the attribute definition table. The type MAY be explicitly declared using xsi:type="xs:string".
• Attributes marked as non-multi-valued MUST NOT contain more than one <AttributeValue> element.
• Attributes marked as multi-valued MAY contain multiple <AttributeValue> elements.
• String matching SHOULD be performed using the caseIgnoreMatch rule as defined in X.520.

Scoped Attributes

A scoped attribute expresses its value as a string of the form value@scope, where the scope represents the Identity Provider's security domain.

The scope typically corresponds to the organization’s domain name, but is not limited to it, and MUST be declared in the Identity Provider's metadata (the <shibmd:Scope> element).

An Identity Provider that releases scoped attributes MUST be authorized to use the corresponding scope values. Such scopes MUST be registered with the federation and, upon approval by the federation operator, included in the Identity Provider's metadata.

A Relying Party consuming a scoped attribute SHOULD verify that the issuing IdP is authorized to assert the given scope. This verification is performed by checking the Identity Provider's metadata entry, as described in Section 2.1.4 Scope of the SAML 2.0 WebSSO Technology Profile.

Example

The following example illustrates how attributes defined in this specification may be represented in a SAML 2.0 assertion issued by an Identity Provider.

...

    <saml2:AttributeValue 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xsi:type="xs:string">
        vole-x2h5-qmgi@minorganisation.se7803e459-881d-416f-a57c-4ce5eda0b79b@example.org
    </saml2:AttributeValue>

</saml2:Attribute>

Attribute Definitions

subject-id

The attribute is a technical identifier assigned by the subject’s home organization to uniquely identify the subject across Relying Parties within the federation.

The value MUST be persistent, stable over time, and globally unique, and MUST NOT be reassigned to another subject.

The identifier MUST be designed such that its value does not directly or indirectly reveal the identity of an individual.

The identifier MUST be constructed as a locally unique value followed by “@” and a scope (security domain). The scope typically corresponds to the organization’s domain name, but is not limited to it, and MUST be declared in the Identity Provider’s metadata (Scope element). The combination of identifier the locally unique value and scope uniquely identifies the subject within the federation.

pairwise-id

The attribute is a technical identifier assigned by the subject’s home organization to uniquely identify the subject on a per–Relying Party basis.

The value MUST be persistent and stable over time for a given subject–Relying Party pair, and MUST NOT be reassigned to another subject.

The identifier MUST be designed such that its value does not directly or indirectly reveal the identity of an individual.

The identifier MUST be generated in a manner that prevents the subject from being correlated across different Relying Parties.

The identifier MUST be constructed as a locally unique identifier followed by “@” and a scope (security domain). The scope typically corresponds to the organization’s domain name, but is not limited to it, and MUST be declared in the Identity Provider’s metadata (Scope element).. 

givenName

The given name (first name) of the subject.

sn

The surname (family name) of the subject.

displayName

A name that is suitable for display to end-users, typically a combination of given name and surname.

mail

The email address of the subject.

...

*) The mail attribute MUST be treated as a scoped attribute if and only if the applicable attribute release policy explicitly designates it as scoped. Otherwise, it MUST be treated as non-scoped.

telephoneNumber

The telephone number of the subject.

...

mobile

A mobile (cellular) telephone number of the subject.

...

o

The name of the organization to which the subject belongs.

ou

The name of an organizational unit within the organization to which the subject belongs.

...

organizationIdentifier

A unique identifier for the organization to which the subject is affiliated.

...