[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: The Case for SAML Attribute Profiles
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]