Who needs SAML V2.0 Attribute profiles?

The last thing I looked at was <saml:Attribute>'s from the example in the interface description for the revised E-Authentication Architecture (Se the post SAML V2.0 Assertion example from "E-Authentication Federation Architecture 2.0 Interface Specifications"). Taking a step up from what ever is the right naming for the attributes, there the question about NameFormat and in general the chosen attribute profile, if any and what about the X.500/LDAP Attribute profile.

Attribute profiles in E-Authentication

In section 1.7.3.4 <AttributeStatement> Element it's profiled like:

• The CS MUST send exactly one <AttributeStatement> to an RP during the first transmission of an <Assertion> for a particular <Subject>.
• Each subsequent <Assertion> MUST contain no more than one <AttributeStatement>.
• Each <Attribute> MUST NOT be encrypted.

<AttributeStatement> is a child element of <Assertion> and schema definition makes room for zero or many AttributeStatement's. The reason for making it possibly to have multiple AttributeStatement's is over my head since one could do and would simply things a bit. That makes the requirement of the first to bullets very reasonably and they need the first Assertion to carry the mandatory attributes. The XML Schema definition is :

   57     <element name="Assertion" type="saml:AssertionType"/>
   58     <complexType name="AssertionType">
   59         <sequence>
   60             <element ref="saml:Issuer"/>
   61             <element ref="ds:Signature" minOccurs="0"/>
   62             <element ref="saml:Subject" minOccurs="0"/>
   63             <element ref="saml:Conditions" minOccurs="0"/>
   64             <element ref="saml:Advice" minOccurs="0"/>
   65             <choice minOccurs="0" maxOccurs="unbounded">
   66                 <element ref="saml:Statement"/>
   67                 <element ref="saml:AuthnStatement"/>
   68                 <element ref="saml:AuthzDecisionStatement"/>
   69                 <element ref="saml:AttributeStatement"/>
   70             </choice>
   71         </sequence>
   72         <attribute name="Version" type="string" use="required"/>
   73         <attribute name="ID" type="ID" use="required"/>
   74         <attribute name="IssueInstant" type="dateTime" use="required"/>
   75     </complexType>

The way the last bullet is formatted is a bit odd, since an encrypted <Attribute> would be represented by an <EncryptedAttribute>.

  260     <element name="AttributeStatement" type="saml:AttributeStatementType"/>
  261     <complexType name="AttributeStatementType">
  262         <complexContent>
  263             <extension base="saml:StatementAbstractType">
  264                 <choice maxOccurs="unbounded">
  265                     <element ref="saml:Attribute"/>
  266                     <element ref="saml:EncryptedAttribute"/>
  267                 </choice>
  268             </extension>
  269         </complexContent>
  270     </complexType>

The next part of the E-Authentication profile dictates:

• If present, NameFormat of <Attribute> MUST be one of the following:
  • urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
  • urn:oasis:names:tc:SAML:2.0:attrname-format:uri
  • urn:oasis:names:tc:SAML:2.0:attrname-format:basic
• The actual Name MUST be a URI.
• The optional attribute FriendlyName MAY be used to provide a human readable label for the attribute.
• Where the definition of an attribute includes one or more descriptors for the attribute, FriendlyName, if present, MUST be one of the defined descriptors.

The first bullet simply excludes any extension from the SAML V2.0 CORE specification (8.2 Attribute Name Format Identifiers):

The following identifiers MAY be used in the NameFormat attribute defined on the AttributeType complex type to refer to the classification of the attribute name for purposes of interpreting the name.

As it states can is because it's optional. The definition of the NameFormat attribute is in 2.7.3.1 Element <Attribute>:

NameFormat [Optional]

A URI reference representing the classification of the attribute name for purposes of interpreting the name. See Section 8.2 for some URI references that MAY be used as the value of the NameFormat attribute and their associated descriptions and processing rules. If no NameFormat value is provided, the identifier urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified (see Section 8.2.1) is in effect.

The schema definition:

  271     <element name="Attribute" type="saml:AttributeType"/>
  272     <complexType name="AttributeType">
  273         <sequence>
  274             <element ref="saml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/>
  275         </sequence>
  276         <attribute name="Name" type="string" use="required"/>
  277         <attribute name="NameFormat" type="anyURI" use="optional"/>
  278         <attribute name="FriendlyName" type="string" use="optional"/>
  279         <anyAttribute namespace="##other" processContents="lax"/>
  280     </complexType>
  281     <element name="AttributeValue" type="anyType" nillable="true"/>

The only required xml attribute is Name that's defined as xs:string in the schema.

Getting back to the NameFormat identifiers, the default value was urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified, notice that they forgot to put it into the schema. The urn:oasis:names:tc:SAML:2.0:attrname-format:uri put's the following constraints on the Name xml attribute:

The attribute name follows the convention for URI references [RFC 2396], for example as used in XACML [XACML] attribute identifiers. The interpretation of the URI content or naming scheme is applicationspecific. See [SAMLProf] for attribute profiles that make use of this identifier.

In words of XML Schema this means that the Name XML attribute should conform to the syntax of the built-in datatype xs:anyURI.

The last identifier urn:oasis:names:tc:SAML:2.0:attrname-format:basic:

The class of strings acceptable as the attribute name MUST be drawn from the set of values belonging to the primitive type xs:Name as defined in [Schema2] Section 3.3.6. See [SAMLProf] for attribute profiles that make use of this identifier.

The XML Schema specification bases the defintion on XML (Second Edition) recommendation where Name is defined as:

[4]     NameChar     ::=     Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]     Name     ::=     (Letter | '_' | ':') (NameChar)*

That it's defined on xs:token doesn't change the fact that it's strange why xs:anyURI is defined as a restricted xs:Name, except that it would make it a built-in derived type instead of a built-in primitive type as can be seen on the Built-in Datatype Hierachy.

This makes the requirement that all Name XML attributes should be URI's with the option for all three Attribute Name Identifiers a little odd, since urn:oasis:names:tc:SAML:2.0:attrname-format:uri is a perfect match.

Conformance

The SAML V2.0 Conformance describes the requirements in section 3.3 Implementation of SAML-Defined Identifiers (my bold and italic):

All relevant operational modes MUST implement the following SAML-defined identifiers:

• All Attribute Name Format identifiers defined in Section 8.2 of [SAMLCore]
• All Name Identifier Format identifiers defined in Section 8.3 of [SAMLCore]

Conforming SAML implementations MUST permit the use of all identifier constants described in Sections 8.2 and 8.3 when producing and consuming SAML messages. SAML message producers MUST be able to create messages and SAML message consumers MUST be able to process messages with any of the constants defined in these sections.

Sections 8.3.7 (persistent name identifiers) and 8.3.8 (transient name identifiers) define normative processing rules for the producer of such identifiers. All normative processing rules in Sections 8.3.7 and 8.3.8 MUST be supported by conforming implementations. The remaining identifiers in Sections 8.2 and 8.3 specify no normative processing rules. Hence, generation and consumption of these identifiers is meaningful only when the generating and consuming parties have externally-defined agreement on the semantic interpretation of the identifiers.

This makes support for the three Attribute Name Identifiers mandatory, but make it clear how to handle unkown attributes like the ones defined for the Attribute Profiles like X.500/LDAP. To be on the safe side I'll have to assume that none of these are required in terms of conformance.

Project Liberty

The Liberty Alliance has adopted SAML V2.0 an have they're own interoperability program called Liberty Interoperable. This program does extend the conformance program of SAML V2.0 as described in Liberty Interoperability Testing Procedures for SAML 2.0 v2.0. In 3.1.9. Attribute Profiles it describes:

[SAMLConf] makes no normative statements about which Attribute Profiles in [SAMLProf] are required to be supported by SAML Attribute Authority or a SAML Requestor. These are the profiles described in [SAMLProf]:

1. Basic
2. X.500/LDAP
3. UUID
4. DCE PAC
5. XACML

Of these, this document only describes testing procedures for the Basic and X.500/LDAP profiles, and does not describe any testing procedures regarding the other profiles.

So they agree that there is no conformance requirements for Attribute Profiles, but they do cover both Basic and X.500/LDAP. Unfortunately I haven't found any more information on the specifics as can be seen in section 3.6. LDAP Attribute Profile: "Pending SSTC resolution of issues with this profile.". This has been solved with New SAML V2.0 X.500/LDAP Attribute Profile , and since there's an SAML 2.0 Interoperability Test coming up in October, they are probably working on this document right now.

New Zealand Security Assertion Messaging Standard

The latest version is Draft v0.9 of June 2006 with the disclaimer Work in progress: not issued for public consultation. The nzsams defines the profile for NZ SAMS compliance in terms of Attribute profiles in chapter 12. NZ SAMS Constraints on the OASIS SAML v2.0 CORE (Assertions and Protocols, with the second bullet:

Attribute Name Format Identifiers (section 8.2): Basic only is REQUIRED. Remaining Attribute Name Format Identifiers (Unspecified, URI Reference) are NOT REQUIRED.

The choose only urn:oasis:names:tc:SAML:2.0:attrname-format:basic, but as covered above they can use all names the would conform to the other two attributes aswell.

Who needs them?

Summing up on the usage of Attribute Profiles in usage profiles and SAML V2.0 conformance doesn't really show a need for attribute profiles. I haven't thought out exactly why, but one reason must be that there not the need for global plug-and-play with attributes since much more is involved and along is pleanty of room for externally-defined agreement on the semantic interpretation of the identifiers, names/semantics and syntax