SAML V2.0 Confirmation Method Identifiers - ahem, is this crystal clear?

A few days ago I started to read the Web Services Security: SAML Token Profile 1.1 [PDF], just to discover that it was far more complicated than I had expected (I am naive) and in particular that I didn't have the sufficient understanding of Confirmation Method Identifiers, so before reading further I had to return to the SAML V2.0 specifications. This post covers what I found, which is surprisingly little.

Trying to take this from the top, the <SubjectConfirmation> which is a child element of <Subject>, is defined as (in [SAMLCore] in section '2.4.1.1'):

The <SubjectConfirmation> element provides the means for a relying party to verify the correspondence of the subject of the assertion with the party with whom the relying party is communicating. It contains the following attributes and elements:

Method [Required]

A URI reference that identifies a protocol or mechanism to be used to confirm the subject. URI references identifying SAML-defined confirmation methods are currently defined in the SAML profiles specification [SAMLProf].

The XML Schema representation of this is:

   90     <element name="SubjectConfirmation" type="saml:SubjectConfirmationType"/>
   91     <complexType name="SubjectConfirmationType">
   92         <sequence>
   93             <choice minOccurs="0">
   94                 <element ref="saml:BaseID"/>
   95                 <element ref="saml:NameID"/>
   96                 <element ref="saml:EncryptedID"/>
   97             </choice>
   98             <element ref="saml:SubjectConfirmationData" minOccurs="0"/>
   99         </sequence>
  100         <attribute name="Method" type="anyURI" use="required"/>
  101     </complexType>

I've reread both the element description several times and it still isn't clear what this is really about, but the Method XML attribute carries an identifier for the means as an protocol or mechanism.

Before diving deeper let's make it clear where it's used. The SubjectType carries it, but the XML Schema representation is not as simple as the description in SAMLCore:

   77     <complexType name="SubjectType">
   78         <choice>
   79             <sequence>
   80                 <choice>
   81                     <element ref="saml:BaseID"/>
   82                     <element ref="saml:NameID"/>
   83                     <element ref="saml:EncryptedID"/>
   84                 </choice>
   85                 <element ref="saml:SubjectConfirmation" minOccurs="0" maxOccurs="unbounded"/>
   86             </sequence>
   87             <element ref="saml:SubjectConfirmation" maxOccurs="unbounded"/>
   88         </choice>
   89     </complexType>

It can occur at two levels and according to the Schema it is in fact required (the last one) and is unbounded as described, so it's possible to have many means to verify the correspondence.

As stated the SAML-defined confirmation methods can be found in Profiles for the OASIS SAML V2.0. Here I had hoped for some more in depth description, but that's not really the case. Go have a read for yuorself, but I'll not dwelve at it because there are actually no less than three erratas this chapter (and also some to SAMLCore):

• E40: Holder of Key
• E47: Clarification on SubjectConfirmation
• E56: Confirmation Method Typo

Three SAML-defined Confirmation Method Identifiers are listed in chapter 3:

• urn:oasis:names:tc:SAML:2.0:cm:holder-of-key
• urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
• urn:oasis:names:tc:SAML:2.0:cm:bearer

Bearer

The term bearer is not intuitive to me, the best bet for the danish term is 'drager, 'ihændehaver' or 'overbringer'. The description is:

The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using the attributes that MAY be present in the element, as defined by [SAMLCore].

sender-vouches

This more clearly described:

Indicates that no other information is available about the context of use of the assertion. The relying party SHOULD utilize other means to determine if it should process the assertion further, subject to optional constraints on confirmation using the attributes that MAY be present in the <SubjectConfirmationData> element, as defined by [SAMLCore].

holder-of-key

Finally urn:oasis:names:tc:SAML:2.0:cm:holder-of-key

One or more <ds:KeyInfo> elements MUST be present within the <SubjectConfirmationData> element. An xsi:type attribute MAY be present in the <SubjectConfirmationData> element and, if present, MUST be set to saml:KeyInfoConfirmationDataType (the namespace prefix is arbitrary but must reference the SAML assertion namespace).

The referenced parts are in XML Schema:

  102     <element name="SubjectConfirmationData" type="saml:SubjectConfirmationDataType"/>
  103     <complexType name="SubjectConfirmationDataType" mixed="true">
  104         <complexContent>
  105             <restriction base="anyType">
  106                 <sequence>
  107                     <any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  108                 </sequence>
  109                 <attribute name="NotBefore" type="dateTime" use="optional"/>
  110                 <attribute name="NotOnOrAfter" type="dateTime" use="optional"/>
  111                 <attribute name="Recipient" type="anyURI" use="optional"/>
  112                 <attribute name="InResponseTo" type="NCName" use="optional"/>
  113                 <attribute name="Address" type="string" use="optional"/>
  114                 <anyAttribute namespace="##other" processContents="lax"/>
  115             </restriction>
  116         </complexContent>
  117     </complexType>

and

  118     <complexType name="KeyInfoConfirmationDataType" mixed="false">
  119         <complexContent>
  120             <restriction base="saml:SubjectConfirmationDataType">
  121                 <sequence>
  122                     <element ref="ds:KeyInfo" maxOccurs="unbounded"/>
  123                 </sequence>
  124             </restriction>
  125         </complexContent>
  126     </complexType>

This isn't as clear as I had hoped, but then I found a Shibboleth wiki entry by Scott Cantor on SubjectConfirmation that does a much better job on describing holder-of-key

SubjectConfirmation attaches specific security technologies and constraints to an assertion such that it becomes not only a stand-alone package of information but also a SecurityToken. That is, an entity can use it to prove something about itself to a relying party in order to accomplish some task.

An example illustrates this. Imagine an X.509 certificate. The certificate combined with the private key is a security token. A client can prove ownership of the key, and by attaching the certificate, the relying party can accept the claims inside the certificate if it trusts the issuer.

By itself, a SAML assertion resembles a certificate, but it lacks the key material. The client can't do anything to prove its right to use the assertion. SubjectConfirmation can be used to extend the SAML assertion into the security-specific domain of public key cryptography. By embedding a public key inside a HolderOfKey SubjectConfirmation , the issuer enables a client that can prove ownership of the key to use the assertion, while nobody else can do so. This doesn't turn the assertion into a certificate, but it connects a particular security layer (public key crypto) with SAML, resulting in a SecurityToken.

Note that the security layer could be "null", as in the case of a BearerSubjectConfirmation. This grants anybody holding the assertion the ability to use it (subject to other constraints). Thus, any assertion can be turned into a weak SecurityToken by including a BearerSubjectConfirmation.

I would like to say that thes explains it all to me, but it doesn't. The first part talks on generating a general security token. This matches the use in what i startet this post with, the SAML token profile for WSS. The last part though say that urn:oasis:names:tc:SAML:2.0:cm:bearer makes it a weak security token.

I can only conclude that what I had hoped to be an easy readup has just confused me at a higher level. For now I'll just accept the three known Confirmation Method Identifiers, and then later some day I'll me stuble upon some information that can clarify it for me.

WSRP non-normative Conformance: Use Profiles

The Web Services for Remote Portlets Specification, V1.0 [PDF], from August 2003, does not have any profiling or conformance requirements above what's mandated by the specification it self. Since the specification contains several optional features interoperability is in jeopardy.

The specification is aware of this as in section "1.2.2 Producer":

In order to allow different levels of sophistication for both the Producer and Consumer, parts of this functionality are optional. Various examples of how a Producer might implement particular functionality for varying levels of sophistication and with regards to implementing some of the optional portions of the protocol are contained throughout this document.

A the XML Conference in 2003 a couple of IBM guys did a presentation on WSRP called Enabling Interactive, Presentation-Oriented Content Services Through the WSRP Standard [HTML] and in the Future Work section there's a first hint: ...the TC works on use profile definitions and conformance assertions to help guide both the production and marketing of those implementations....

The Web Services for Remote Portlets 1.0 Primer [HTML], Committee Draft 1.01 from 25 January 2005, is a newer document and has a reference to the WSRP Conformance Test Kit on from IBM's AlphaWorks site. It was lat updated June 30 2004, that's more the 3 years ago. In the text it says In this release of the test kit, not all conformance statements are tested. Additional test cases will be added as they become available. This certainly is the smell of an abandoned project that was never completed. In the description on how it works is goes:

The architecture of the WSRP Conformance Test Kit includes a monitor process for non-invasively collecting Web service messages between a client and a server. Once the messages are logged, an offline analyzer process examines the log, determines if the messages conform to the specification, and produces a conformance report. An XML file describing the test cases is read by the analyzer at run time. This XML file is called the WSRPProfileTestAssertions.xml.

A post to the forum by Konrad touches on the same from a more technical perspektive called WSRP Conformance Toolkit outdated?.

So this is strict conformance to the requirements found in the specification and has nothing to do whit profiles. There's also a link to a Microsoft formatted spreadsheet called WSRP Conformance Statements

In section 7 Use Profiles it finally turns up:

The purpose of use profiles is to provide a well-defined palette of functionality for Producers and Consumers. By qualifying a Producer or a Consumer implementation with a use profile palette, implementers can indicate the level of functionality supported. WSRP use profiles are non-normative, and should be regarded as general guidelines. Implementers will likely compose their implementations by selecting from a “palette” of functionality, and this section provides some guidance on how to map these use profiles across several functional axes. Refer to [9] for a complete description of use profiles.

WSRP use profiles declare following levels for Producers:

1. Base Level: The Producer implements just the required elements of the WSRP Specification.
2. Simple Level: The Producer implements certain optional/advanced features in addition to whatever is required at the base level.
3. Complex Level: Complex level Producers implement most of the optional/advanced features of the WSRP specification.

The following are the use profiles for Consumers:

1. Base Level: The Consumer implements just the required elements of the WSRP Specification.
2. Simple Level: The Consumer implements certain optional/advanced features in addition to whatever is required at the base level.
3. Medium Level: Medium level Consumers may implement a larger set of the optional/advanced features of the WSRP specification.
4. Complex Level: Complex level Consumers provide extended features (such as custom modes and window states).

The use profiles are intended to simplify the possible combinations of support for optional areas of the WSRP specification. Each profile specifies a certain set of functionality as supported. While an implementation may also support other optional functions, specifying the supported use profile helps customers to compare the support offered by implementations.

A Consumer and Producer have different motivations in achieving higher levels. A Producer need only implement the functionality required by the portlets it is offering. Unless a Consumer knows that it will only be consuming portlets from a Producer of a given level, it should provide all levels so that any portlet can function properly. The Consumer should not assume that there is graceful degradation of functionality if it does not implement certain functionality. For example, if a Consumer does not provide, say, registration, a portlet from a Producer requiring registration will not function at all.

Also note that there is not a one-to one correspondence with Producer Levels and Consumer levels; e.g. the base consumer level is expected to handle the initCookie operation, while the base Producer level does not require this operation.

This is all based upon a document called WSRP Use Profile [DOC]. The document is quite old, 31 july 2003, and written by Alan Kropp. It's very unformal and there's not a link on the TC homepage. Under "Functional Areas" theres a hint to which concerns have been put into this work (my bold):

An overriding concern in describing the different levels is to maximize basic interoperability, regardless of the implementation choices made. Certainly some combinations of Consumer and Producer implementation may not yield optimal results for the end-user; this is to be expected, particularly when dealing with minimal implementations. However, even base implementations should be capable of interacting with their more sophisticated counterparts, at a sufficient level of functionality, to provide even the most rudimentary result (i.e., not a fault message) to the end-user.

The following functional areas has been identified:

• Caching
• Cookie Handling
• Modes/Window States
• CSS/Markup
• Extensions
• Handles
• Metadata
• Properties
• User Categories
• User Profile
• Namespacing
• Registration
• Portlet Management
• Session Management
• Miscellaneous
• URL Processing
• URL Rewriting

I haven't the needed insight into WSRP V1.0 feature set to have any qualified opinion about it.

WSRP V2.0 Conformance

Public Review Draft 03 of Web Services for Remote Portlets Specification v2.0, from 22 June 2007, has what's called Conformance Statements in Chapter 15. Its not profiles like the ones suggested for version 1.0 nor the way it's done in SAMl V2.0. It's a summary of requirements and maybe they'll later produce real profiles, since this just gives one level of granularity know for the terms REQUIRED, SHOULD, RECOMMENDED etc.

CSS2 enabled post summeries on main page

Yehaaaa, finally I took the time to create the main page I wanted and I succeeded!. Valid XHTML posts and CSS2 selectors and pseudo-classes did the trick.

I first looked at what others suggested like nevyan.blogspot.com Customize the new blogger template and Expandable Post Summaries from betabloggerfordummies.blogspot.com (heavy site with all light blinking). This was all fine, but I don't want the teaser to be limited by starting a span element. Then I got the idea - since I strive for XHTML compliance (validation being one of them) I'm careful about the markup my posts. I all ways use paragraphs <p>, so what I needed was some way to just show the first paragraph. After some searching I stumbled upon CSS2 :first-child pseudo-class. From then it was just a matter of not showing the rest, except on item pageType. It all comes down to two additions to my template. First some styling to the header:

<b:if cond='data:blog.pageType != "item"'>
div.post-body > p:first-child
{ display:inline; }

div.post-body > * + *
{ display:none; }

</b:if>

This dictates that all other pageType's than item, will display the first paragraph, and all other siblings are hidden. The first and specific CSS instruction take precedence, and the * is an element wild card and the + is for adjacent sibling.

The pageType description is: Can be all, archive, main, or item, with all as the default. The widget will only display on the designated pages of your blog. (All widgets display on the Page Elements tab, regardless of their pageType.)

Then adding a second part to the template (just the part in strong, the start is just to give the context):

<div class='post-header-line-1'/>
   <div class='post-body'>
      <data:post.body />
      <div style='clear: both;'/><!-- clear for photos floats -->
   </div>
   <div class='post-post-body'>
      <b:if cond='data:blog.pageType != "item"'>
         <p style="text-align: right; font-size: 150%"><a expr:href='data:post.url' target='_blank'>Read more</a></p>
      </b:if>
   </div>

I had to add another div section since otherwise it would be hidden with the other parts of the post.

The conclusion is that I'm very happy with it. My posts tend to be long and before my main page was extremely long. Now the main page just holds the titles and first paragraphs, and the rest can be read on the individual item pages. The only downside is that the page as in markup i just as long and people might be confused if a search engine leads to my main page, since the search term might very well be hidden - that's under the assumption that search engines don't care for CSS.

Ups, I almost forgot. I seems to work in Firefox, Konqueror and even IE7! IE6 show the complete posts as before, so no harm done and IE6 is slowly loosing to IE7, so this is much better the expected.

Why use the term "principal" when "user" would do?

Some terms I just accept straight off, some take time getting used to and then some just never seem to settle right. For me the term 'principal' has always be a strange term, and it doesn't connect to the part of my brain that carries the concept of a user. Often it helps if I get an understanding of why the term came to use, since the history often explains a logical or sensible reason for it's usage.

The term is also used in the description of Authentication in Wikipedia:

In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication such as a request to log in. The sender being authenticated, often referred to as the principal, may be a person using a computer, a computer itself or a computer program. A blind credential, in contrast, does not establish identity at all, but only a narrow right or status of the user or program.

This really doesn't explain it to me, so I'll continue my search.

The Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0 [PDF], defines Principal as A system entity whose identity can be authenticated. [X.811] and of interest later in this post Principal Identity as A representation of a principal’s identity, typically an identifier..

The Glossary references X.811 : Information technology - Open Systems Interconnection - Security frameworks for open systems: Authentication framework [PDF]. Here the term is defined in 3.15: principal: An entity whose identity can be authenticated.. Uhmm, a little more is added in section "5.1.1 Identification and authentication":

A principal is an entity whose identity can be authenticated. A principal has one or more distinguishing identifiers associated with it. Authentication services can be used by entities to verify purported identities of principals. A principal’s identity which has been so verified is called an authenticated identity.

Examples of principals that can be identified and hence authenticated are:

• - human users;
• - processes;
• - real open systems;
• - OSI layer entities; and
• - enterprises.

Distinguishing identifiers are required to be unambiguous within a given security domain. Distinguishing identifiers distinguish a principal from others in the same domain, in one of two ways:

• - at a coarse level of granularity, by virtue of membership in a group of entities considered equivalent for purposes of authentication (in this case the entire group is considered to be one principal and has one distinguishing identifier); or
• - at the finest degree of granularity, identifying one and only one entity.

There's more in "5.6 Types of principal":

Principals can be categorized in various ways, such as:

• a) those with passive characteristic(s), e.g. fingerprint, retinal characteristics;
• b) those with information exchange and processing capability;
• c) those with information storage capability; and
• d) those with a unique fixed location.

Principals may fit more than one category [for example, human entities fit a), b) and c)].

So what does this come down to? Well, it looks like they've made quite an academic approach, and that probably why they chose the word principal. One point is that it's not simply a user - it can be a user, but just as well a group of users, a process or as it said an enterprise! So they could no use the term user since the concept is wider.

The article "What Is A Security Principal" on Pluralsight, has the same conclusion.

A security principal is an entity that can be positively identified and verified via a technique known as authentication (WhatIsAuthentication). Usually when people think of security principals, they think of users, but there's a bit more to it than that. I like to think of three different types of principals:

• User principals
• Machine principals
• Service principals

Does this make it clearer to me? Not really - I gladly use the term "user" for a process, since I can abstract what I meant with a user. Maybe someday I'll get the insight when i stumble upon a case that can open it up to me. Any way, hopefully writing this post will help connect the right dots in my brain, so that I'll adopt the term 'principal'.

Wrong 'Content-Type' from web servers - an example from the OASIS 'docs' site

It's often the little things that's the most annoying. For me one of those are documents sent with the wrong Content-Type from web servers. I just encountered it once more on the OASIS docs website, and since so many OASIS standards use xsd and wsdl files this shouldn't happen to one of they're sites.

I wanted to look at the XML Schema for WSRP V2.0 type and it clearly showed up as 'plain/text' in my Firefox browser. Here's the headers (my bold):

wget -S http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-types.xsd
--13:57:26--  http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-types.xsd
           => `wsrp-2.0-types.xsd'
Resolving docs.oasis-open.org... 66.151.234.52
Connecting to docs.oasis-open.org|66.151.234.52|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Sat, 25 Aug 2007 12:05:20 GMT
  Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8
  Last-Modified: Tue, 10 Jul 2007 00:13:00 GMT
  ETag: "a5000f-10875-434dd9fc8db00"
  Accept-Ranges: bytes
  Content-Length: 67701
  Keep-Alive: timeout=10, max=200
  Connection: Keep-Alive
  Content-Type: text/plain
Length: 67,701 (66K) [text/plain]

100%[====================================>] 67,701        55.75K/s

13:57:27 (55.60 KB/s) - `wsrp-2.0-types.xsd' saved [67701/67701]

The web server is an Apache of a recent version (2.2.3), so either this hasn't been added the magic files or i has been deliberately changed by the IT-folks running the web server.

I dowloaded the most recent tarball (version 2.2.4) . In the file docs/conf/mime.types used by mod_mime the most common file extensions are listed. To my surprise xsd isn't there, and the same goes for wsdl. It's just the most basic ones can be found:

application/xhtml+xml           xhtml xht
application/xslt+xml            xslt
application/xml                 xml xsl

Uhmm nothing here, but what about docs/conf/magic used by mod_mime_magic. Here's a hint for detecting XML-files in general:

# XML eXtensible Markup Language, from Linus Walleij <triad@df.lth.se>
0   string      \<?xml      text/xml

and the xsd for WSRP 2.0 types does have the XML-declaration so this should have caught it. For a second I started to wonder if there's a specific Content-Type (mime-type) for XML Schema, but a search gave me nothing.

I conclude that the Content-Type for XML Schema files, should be text/xml and certainly not text/plain. It looks like it's deliberate, for some unknown reason to me. The documentation for mod_mime_magic has a note about performance This module is not for every system. If your system is barely keeping up with its load or if you're performing a web server benchmark, you may not want to enable this because the processing is not free.. But OASIS should for one have added both entries for xsd and wsdl in mime.types and have a scalable web-park without the need for this kind of performance hacks. Also the content is relatively controlled to it's not like they needed to support all kinds of file extensions.

Had i been using IE i would have been presented as 'text/xml' since IE almost ignores the Content-Type and only uses an internal algorithm which also uses the filename suffix on documents, in this case 'xsd'. This behavior isn't right in my eyes and the problems arise when ex. XML-documents are located at URL's that doesn't end with '.xml'.

Danish eGovernment SAML V2.0 profile in hearing

Monday the hearing over the proposal for a Danish eGovernment SAML V2.0 profile started, and it will run until 21. September. There are two documents (both in english):

• SAML Profile for Federation in Danish Public Sector V2.0 (76 pages)
• SAML Profile for SSO in Danish Public Sector V2.0 - Assertion Examples, Version 1.1 (21 pages)

I've fleshed out the examples to XML files and added XML Schema references (and declaring the XML Schema namespace, that was missing in some of them):

• AttributeQuery-example.xml
• AttributeQuery-multiple-attributes-example.xml
• AttributeQuery-response-example.xml
• Authentication-request-example.xml
• Authention-response-example.xml
• oces-profile-assertion-example.xml
• persistent-pseudonym-assertion-example.xml

it's a very smooth read and i haven't been through all of it yet, but the web SSO profile is basiclly the same as the one for eAuthentication.

Privacy Impact Assessment (PIA) - Aliens have a right for P3P as well

The OMB has written Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 (M-03-22). It's a rather long and terse document, that even scares junior spec readers like myself. I ran into into it when searching for privacy initiatives. In Attachment A - E-Government Act Section 208 Implementation Guidance section II. Privacy Impact Assessment subsection A. Definitions. there's a glossary.

Individual - means a citizen of the United States or an alien lawfully admitted for permanent residence. (Agencies may, consistent with individual practice, choose to extend the protections of the Privacy Act and E-Government Act to businesses, sole proprietors, aliens, etc.)

As english is a non-native language to me, this is a great laugh :-). Though the meaning is less spectacular as can be seen in wikipedias entry on the term Alien in U.S. law:

In U.S. law, an alien is a person who owes political allegiance to another country or government and not a native or naturalized citizen of the land where they are found.

The sixth term defines the PIA (my formatting)

Privacy Impact Assessment (PIA) - is an analysis of how information is handled:

1. to ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy,
2. to determine the risks and effects of collecting, maintaining and disseminating information in identifiable form in an electronic information system, and
3. to examine and evaluate protections and alternative processes for handling information to mitigate potential privacy risks.

This sounds all fair, though it's a lot of hard work creating and keeping up to date. The seventh and last term:

Privacy policy in standardized machine-readable format - means a statement about site privacy practices written in a standard computer language (not English text) that can be read automatically by a web browser.

Here the obvious candidate is P3P. In section IV. Privacy Policies in Machine-Readable Formats the requirements are:

1. Actions.
   1. Agencies must adopt machine readable technology that alerts users automatically about whether site privacy practices match their personal privacy preferences. Such technology enables users to make an informed choice about whether to conduct business with that site.
   2. OMB encourages agencies to adopt other privacy protective tools that become available as the technology advances.
2. Reporting Requirement. Agencies must develop a timetable for translating their privacy policies into a standardized machine-readable format. The timetable must include achievable milestones that show the agency’s progress toward implementation over the next year. Agencies must include this timetable in their reports to OMB (see Section VII).

The last mentioned report is not eazy-piecy. In section VII. Reporting Requirements it goes:

Agencies are required to submit an annual report on compliance with this guidance to OMB as part of their annual E-Government Act status report. The first reports are due to OMB by December 15, 2003. All agencies that use information technology systems and conduct electronic information collection activities must complete a report on compliance with this guidance, whether or not they submit budgets to OMB.

Reports must address the following four elements:

1. Information technology systems or information collections for which PIAs were conducted. Include the mechanism by which the PIA was made publicly available (website, Federal Register, other), whether the PIA was made publicly available in full, summary form or not at all (if in summary form or not at all, explain), and, if made available in conjunction with an ICR or SOR, the publication date.
2. Persistent tracking technology uses. If persistent tracking technology is authorized, include the need that compels use of the technology, the safeguards instituted to protect the information collected, the agency official approving use of the tracking technology, and the actual privacy policy notification of such use.
3. Agency achievement of goals for machine readability: Include goals for and progress toward achieving compatibility of privacy policies with machine-readable privacy protection technology.
4. Contact information. Include the individual(s) (name and title) appointed by the head of the Executive Department or agency to serve as the agency’s principal contact(s) for information technology/web matters and the individual (name and title) primarily responsible for privacy policies.

Whouzz, this is done right and with required documentation. When I get the energy and courage I'll go look for a such a policy on a U.S. Government website.

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