...

This specification defines standardised a common attribute profile, consisting of attribute names and their associated semantics for attributes that may be communicated within a SAML federation, for use in the Swedish Internet Foundation's SAML-based federations. The attribute set is intended as a reference data set of attributes that may be released to support consistent and interoperable attribute release from Identity Providers to Relying Parties.

The attributes described are intended to support generic defined in this specification support common identity and access management use cases, including user subject identification, personal naming, and contact information. 

The specification is designed to be domain-neutral and applicable may be adopted across different sectors and servicesfederation environments. Its purpose is to promote consistency and interoperability between Identity Providers and Relying Parties by establishing a baseline common definitions for attribute naming, semantics, and usage.

Members participating in the federation that require the exchange of these attributes Federations and other parties that choose to adopt this specification are expected to use the definitions provided in this specificationdefined attributes consistently when exchanging attribute information.

This specification does not mandate define a mandatory minimum set of attributes to that must be released. Relying Parties determine attribute requirements based on their service-specific needs. Identity Providers may also release additional attributes beyond those defined in this specification, subject to applicable policy and operational requirements.

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

Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.

SAML Attribute Representation

SAML Attribute Format

When attributes an attribute defined in this specification are usedis conveyed in SAML 2.0, the following requirements apply:

• The Each attribute SHALL be represented using a <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 the URI as defined for the attribute in this specification. Attribute names are expressed as URIs in the form of URLsdefined by this specification use the https scheme.
• 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 Unless otherwise specified in the relevant attribute definition, each <AttributeValue> element MUST contain a value of type xs:string. The type MAY be explicitly declared using xsi:type="xs:string".
• Attributes marked designated as nonsingle-multi-valued MUST NOT contain more than one <AttributeValue> element.
• Attributes marked designated as multi-valued MAY contain multiple more than one <AttributeValue> elements.String matching SHOULD be performed using the caseIgnoreMatch rule as defined in X.520
• Unless otherwise specified in the relevant attribute definition, this specification does not override the default SAML string comparison rules.

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 domainform value@scope.

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)portion qualifies the value within a namespace controlled by the asserting Identity Provider. The meaning and interpretation of scope are attribute-specific unless otherwise defined for a particular attribute or profile.

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 MUST NOT assert a scoped attribute value containing a scope that it is not authorized to use.

Where metadata-based scope validation is used, the permitted scope values for an Identity Provider MUST be declared in metadata using the <shibmd:Scope> element.

A Relying Party consuming that consumes a scoped attribute SHOULD verify that the asserted scope is permitted for the issuing IdP is authorized to assert the given scope. This verification is performed by checking the Identity Provider by comparing the scope portion of the attribute value against the <shibmd:Scope> values published in that Identity Provider's metadata entry, as described in Section . See also section 2.1.4 Scope of the in 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:Attribute 
    Name="https://example.org/attributes/subject-id"
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
    FriendlyName="subject-id">

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

</saml2:Attribute>

Attribute Definitions

subject-id

...

...

The email address of the subject.

Multiple email addresses MAY be provided. Values Values MUST be syntactically valid email addresses.

...

telephoneNumber

The telephone number of the subject.

...