MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Reminder: SSTC SAML Attribute Metadata Focus Group
XACML TC members:
The SSTC will be discussing our recommendations for SAML
Attribute Metadata at their Focus Group tomorrow (Tuesday) from
noon to 1:30pm U.S. Eastern time (9 to 10:30am U.S. Pacific
time). You are all invited to participate.
The dial-in number is +1 865 673 6950 , code 351-8396#
Our recommendations are appended. They are in
XACML:
http://lists.oasis-open.org/archives/xacml/200404/msg00053.html
SSTC:
http://lists.oasis-open.org/archives/security-services/200404/msg00019.html
Anne
--
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
From: Anne Anderson <Anne.Anderson@Sun.COM>
Date: Thu, 08 Apr 2004 11:44:54 -0400
To: security-services@lists.oasis-open.org
Cc: XACML TC <xacml@lists.oasis-open.org>
Subject: [xacml] 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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]