RE: [xacml] XACML TC position on SAML Attribute meta-data

["Daniel Engovatov" <dengovatov@bea.com>]

In regard to N.4:  I think we should seriously consider adding
"scope"/"namespace"/"source" as a separate attribute, not part of the
attribute name.
That will allow for much more flexibility and interoperability in
expressing context view of enterprise data: it typically has myriad of
sources not easily grouped into our 4 predefined scopes (<subject>,
<resource>, <action>, <environment>).  Concatenation and other form of
name mangling is usually a very non-robust way for name conflict
resolution.

This separated attributes may be made part of existing "scopes", or the
concept of scope can be made extensible.

So, I would not sign on item 4)  I agree with others.

Daniel.


-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] 
Sent: Wednesday, April 07, 2004 7:26 AM
To: XACML TC
Subject: [xacml] XACML TC position on SAML Attribute meta-data

I took an action item to spell out "the XACML position" for the
SSTC.  This is my understanding.  Any changes?

Anne

****************DRAFT*********************
The XACML TC recommends that

1) Attribute metadata consist of a single name and a type, where
   the name (anyURI) describes which attribute and the type
   describes the syntax of the Attribute value.

   Rationale: Specifying the type in the attribute metadata
   rather than as part of the attribute value allows type
   checking systems to evaluate the type even when the value is
   not yet available and without requiring evaluation of the
   value.  It separates "type" from "value" for cases where the
   "value" must be operated on (e.g. addition, up-casing, etc.)

   Use of multiple name components complicates references to
   Attributes, as each reference MUST include multiple name
   components to avoid ambiguity.  If name components must always
   be specified, it is easiest to specify them in one metadata
   component rather than in several.

2) If type (value syntax) is not mandated as Attribute metadata,
   that an optional XML attribute for holding type information be
   specified.

   Rationale: By having a specified type attribute, systems that
   choose to use type in the metadata will be interoperable.
   XACML is a use case for where type checking is required, and
   where such metadata is used.  By specifying a well-defined
   name for this metadata in SAML, XACML can specify a SAML
   profile for mapping SAML Attributes to XACML attributes that
   will be interoperable with any SAML implementation that
   provides type metadata.

3) That arbitrary XML attributes NOT be supported.  Instead,
   include any proposed well-defined specific metadata as
   optional metadata in the SAML specification.

   Rationale: By having specified XML attribute names, systems
   that choose to use additional metadata with the same semantic
   will be interoperable.  Since the additional XML attributes
   are optional, they do not impact systems that choose not to
   use them.  This also allows systems that must concatenate name
   elements to profile an order in which various elements will be
   listed in the concatenation.

4) If SAML chooses to allow multiple Attribute name components, 
   that SAML choose a type for those components that will support
   concatenation when a single name must be created.  For
   example, "urn" would work, but "anyURI" would not, since
   various URI schemes have different sets of allowed characters,
   and there is no single separator character or sequence of
   characters that will work with all of them.

   Rationale: By supporting concatenation, those systems that do
   not support all the SAML metadata elements can produce SAML
   profiles that allow unambiguous conversion of SAML names to
   other names.  This will allow XACML, for example, to profile
   how to convert a SAML Attribute to an XACML Attribute
   unambiguously.

5) If SAML chooses to allow arbitrary attributes in the Attribute
   metadata, that they be supported only in addition to a full
   list of all proposed well-defined metadata attributes.  The
   specification should state that additional attributes SHALL be
   used only if no specified attribute has the same semantic.

   Rationale: By using specified attribute names, systems are
   more likely to be interoperable and fewer cases will be
   unprofilable.

Anne Anderson
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgro
up.php.