The Case for SAML Attribute Profiles

["Mishra, Prateek" <pmishra@netegrity.com>]

This message makes the following proposals:

(1) The SAML Core document retain a fairly high-level approach towards
<samlp:AttributeQuery> and <saml:AttributeDesignator> elements. In
particular, it should not specify elements/attributes/values which are of
interest only to particular communities.

This would mean removal of <samlp:Resource> and Attribute NameFormat
identifiers other than
urn:oasis:names:tc:SAML:2.0:valuetype-format:unspecified from the text.

(2) Guidance on creating specific attribute profiles be provided in a
separate document (A first cut is available in the most recent draft of the
Attribute Profiles for SAML 2.0,
draft-hughes-mishra-baseline-attributes-03.pdf). This would include the
naming profiles (ValueType attribute), any additional XML attributes defined
by the profile, syntax for attribute names, rules for determining equality
of attribute designators.

(3) Specific attribute profiles of interest to the SAML community be added
to the document. The current document includes definitions of a X.500/LDAP
and DCE UUID profile. 

----------------------------------------------------------------------------

On a more discursive note, I would argue that this approach unifies several
distinct strands in SAML 2.0. Initially, it appeared to me that the core
document provided adequate general structure for attributes and that the
profile document would play a much more limited role --- for example,
describing a couple of "baseline" attribute profiles. 

Lately, there have been a number of discussions that have shown this
approach to have some challenges. Instead, an approach that more directly
focusses on the creation of profiles seems to me to be the better solution.

These discussions include, the profile described by Rob at the F2F which
consists of an attribute defined as a combination of a name and a source
field. The source field is interpreted as a qualifier for the name; two
attribute designators are equal only when both fields are equal as strings.
An additional XML attribute is required for the "source" field. 

The XACML case also appears to constitute a separate profile. 

http://lists.oasis-open.org/archives/security-services/200404/msg00019.html

XACML has a specific need for carrying a type designator with the
<saml:AttributeDesignator> element.  

Finally, there have been many deployments that use some form of attribute
statement. One challenge with creating these deployments is finding the
right language to describe the attribute statements generated/consumed by
each node. Some of these questions are:

Does the deployment require the development of a custom attribute profile?
What is meant by the term "attribute profile" ? Can deployment needs be met
by using one of the profiles given in the specification? 

These questions can be answered appropriately if we build out a framework
based on the three-point proposal given above.