Table of Contents 

Introduction

This specification defines a common attribute profile, consisting of attribute names and their associated semantics, for use in the Swedish Internet Foundation's SAML-based federations. The attribute set is intended to support consistent and interoperable attribute release from Identity Providers to Relying Parties.

The attributes defined in this specification support common identity and access management use cases, including subject identification, personal naming, and contact information.

The specification is domain-neutral and may be adopted across different sectors and federation environments. Its purpose is to promote consistency and interoperability by establishing common definitions for attribute naming, semantics, and usage.

Federations and other parties that choose to adopt this specification are expected to use the defined attributes consistently when exchanging attribute information.

This specification does not define a mandatory minimum set of attributes that must be released. Relying Parties determine attribute requirements based on their service-specific needs. Identity Providers may 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 an attribute defined in this specification is conveyed in SAML 2.0, the following requirements apply:

• Each attribute SHALL be represented using a <saml:Attribute> element.
• The NameFormat attribute MUST have the value urn:oasis:names:tc:SAML:2.0:attrnameformat:uri.
• The Name attribute MUST contain the URI defined for the attribute in this specification.
• The FriendlyName attribute is OPTIONAL.
• 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 designated as single-valued MUST NOT contain more than one <AttributeValue> element.
• Attributes designated as multi-valued MAY contain more than one <AttributeValue> elements.
• Unless otherwise specified in the relevant attribute definition, this specification does not override the default SAML string comparison rules.

Naming Principles

This specification aims to reuse established and widely adopted attribute definitions wherever possible, rather than introducing new attribute names.

Attribute names in this specification have been selected in the following order of precedence:

1. OASIS SAML specifications. 
2. Attributes defined in international standards and specifications (e.g. ITU-T, IETF), identified using URN-based OID namespaces. 
3. OIDs defined at the national level by public authorities or recognized standardization bodies.
4. Custom attributes defined by the Swedish Internet Foundation (“Internetstiftelsen”). 

If no suitable attribute definition exists in the sources listed above, new attribute names may be defined by the Swedish Internet Foundation (“Internetstiftelsen”). Such attribute names use the https URI scheme.

Scoped Attributes

A scoped attribute expresses its value as a string of the form value@scope.

The scope 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 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 that consumes a scoped attribute SHOULD verify that the asserted scope is permitted for the issuing Identity Provider by comparing the scope portion of the attribute value against the <shibmd:Scope> values published in that Identity Provider's metadata. See also section 2.1.4 Scope in SAML 2.0 WebSSO Technology Profile.

Identifier Properties

This section describes identifier properties, including whether they are non-reassignable, opaque, persistent, and unique per relying party.

Identifier	Non-reassigned	Opaque	Persistent	Unique per Relying Party
subject-id
pairwise-id
personalIdentityNumber

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. The combination of 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. 

personalIdentityNumber

The subject’s national civic registration number (i.e. the Swedish “personnummer” or “samordningsnummer” as defined in SKV 704 and SKV 707).

The value MUST consist of 12 digits without a hyphen. 

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.

Values MUST be syntactically valid email addresses.

telephoneNumber

The telephone number of the subject.

Values SHOULD be formatted according to ITU-T Recommendation E.164 where possible.

Multiple values MAY be provided.

mobile

A mobile (cellular) telephone number of the subject.

Values SHOULD be formatted according to ITU-T Recommendation E.164 where possible.

Multiple values MAY be provided.

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.

The value represents an organizational subdivision such as a department or unit. Multiple values MAY be provided if the subject is associated with more than one organizational unit.

The value is not guaranteed to be unique and MUST NOT be used as an identifier.

organizationIdentifier

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

The value MUST be a Swedish company registration number (a.k.a. “organisationsnummer“) formatted as a 10-digit string without hyphens, in accordance with SKV 709.