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: Re: [security-services] XACML TC recommendations for SAML Attributemetadata

(I believe this would get bounced from the XACML list since I'm not on 
it...  Anne, can you please forward?)

I haven't yet seen an agenda for today's SSTC telecon, but I'm assuming 
that the attribute topic will be on it.  This message provides a little 
context going into that discussion.

I believe the latest SSTC changes to attribute information meet your 
request in A (Single Attribute identifier component).  The Name field on 
the Attribute and AttributeDesignator elements is unitary, and can be 
interpreted as a URI if the NameFormat field is set appropriately (the 
default NameFormat is "unspecified", which some SSTC members have a 
strong rationale for keeping).  We originally agreed to this change at 
our February F2F at the behest of the XACML TC, so hopefully this meets 
your needs for uniquely identifying an attribute.  I believe the request 
in E ([if not A] Easy concatenation of metadata) truly becomes moot, 
since with the new unitary naming scheme everything is expected to be 
"concatenated" by default (though there are ways to extend SAML to break 
it out again).

Your requests in B (data type metadata required) and C ([if not B] "data 
type" metadata optional) can be taken as a request to continue making 
the experimental ValueType field available, even though in our 
March/April F2F we favored removing it and pushing such a field into the 
"extensible" part of SAML, for example, a new XML attribute in something 
like an xacml: namespace.  We should discuss this today, in conjunction 
with the following.

Your requests in D (No arbitrary metadata) and F ([If not D] Arbitrary 
metadata only if no duplicate semantics) will also have to be discussed. 
  SAML has always offered extensibility.  The ability to add "arbitrary 
attributes" has always been present, though in the past we required an 
extension schema to be defined for this to work.  Without extensions, 
XACML and others would not be able to layer on top of SAML.  The new 
piece here is the acknowledgment that some deployments have found the 
schema requirement to be onerous; we're therefore allowing attributes to 
be added, e.g., as part of a prose-based profile, in this location where 
we have some evidence that novel fields will be wanted.  Following is my 
personal analysis: I don't believe that the request in F would have much 
effect on interop, though there are perhaps things we could say in our 
documentation on how to create extensions that would incrementally 
improve things.  I support keeping the "arbitrary fields" feature.

Regarding the request in G ("scope/source/namespace" metadata), we 
struggled in our March/April F2F to come up with a clear definition for 
what this field would be for, without encroaching on the other fields 
already accepted, and couldn't really do it; without a crisp definition, 
it would push interop problems right into the core spec.  If you can 
suggest a definition, we'll be able to measure its utility vs. allowing 
people to add their own arbitrary fields with whatever definitions they 



Anne Anderson wrote:

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

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com

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