OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XACML TC recommendations for SAML Attribute metadata


By "metadata", we mean what are now XML attributes specified in
the SAML Attribute element.  We see no impact on XACML if these
attributes are specified in a separate message associated with
the Attribute somehow.

We also see no impact on XACML if SAML chooses to limit its
attributes to one data type (value syntax) per Attribute.  This
would not affect translation of SAML Attributes to XACML
Attributes.  While it means not all XACML Attributes could be
translated into SAML Attributes, we do not see use cases for that
reverse translation.

Specific recommendations:

A. Single Attribute identifier component

   Attribute metadata consist of at most one "identifier"
   component and a data type (value syntax).  The identifier
   (anyURI) should fully specify which Attribute is being
   referenced.

   Rationale: Use of multiple identifier components complicates
   references to Attributes, as each reference MUST include
   multiple identifier components to avoid ambiguity.  If
   multiple identifier components must always be specified, it is
   easiest to specify them in one metadata component rather than
   in several.  It is easy to create a single identifier from
   multiple components by concatenation, but such concatenation
   is best defined and performed by the Attribute source than by
   the Attribute processing system (SAML, XACML).

B. data type metadata required

   Make data type (value syntax) required metadata for a SAML
   Attribute.

   Rationale: Specifying the data 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.  Systems such as XACML must operate on the value
   separately from the type of the value (e.g. addition,
   up-casing), and separating the two makes such operations much
   simpler to implement.

C. [if not B] "data type" metadata optional

   If "data type" (value syntax) is not required Attribute
   metadata, then it should be optional.

   Rationale: By having a specified "data" 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 such data type metadata.

D. No arbitrary metadata

   That arbitrary metadata NOT be supported.  If metadata other
   than a single Attribute identifier and data type are allowed,
   make them all specific optional metadata rather than
   arbitrary.

   Rationale: By having specified Attribute metadata, systems
   that choose to use various metadata with the same semantic
   will be interoperable.  Since the additional metadata are
   optional, they do not impact systems that choose not to use
   them.  This also allows profiling by systems that use fewer
   metadata: they can specify an order in which various metadata
   will be listed in concatenations to create those metadata they
   do support.

E. [if not A] Easy concatenation of metadata

   If SAML chooses to allow multiple metadata components (other
   than identifier and data type), that SAML choose a type for
   those metadata that will support easy and efficient
   concatenation when a single identifier must be created from
   multiple components.  For example, "anyURI" does not work,
   since various URI schemes have different sets of allowed
   characters, and there is no single separator character or
   sequence of characters that will work as a unique component
   separator 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 metadata
   names to their supported names.  This will allow XACML, for
   example, to profile how to convert a SAML Attribute to an
   XACML Attribute unambiguously.

F. [If not D] Arbitrary metadata only if no duplicate semantics

   If SAML chooses to allow arbitrary Attribute metadata, the
   specification should state that additional attributes SHALL be
   used only if no specified metadata has the same semantic.

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

G. One of our members likes the idea of a "scope/source/namespace"
   metadata element separate from the Attribute identifier.

-- 
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]