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

[Anne Anderson <Anne.Anderson@Sun.COM>]

Daniel,

I suggest we separate the issue of support for concatenating name
components in general from the issue of support for a specific
"scope/namespace/source" name component.

So long as a deterministic concatenation order is specified, it
should be possible to omit any name component from a
concatenation if desired.

Anne

On 7 April, Daniel Engovatov writes: RE: [xacml] XACML TC position on SAML Attribute meta-data
 > From: Daniel Engovatov <dengovatov@bea.com>
 > To: Anne.Anderson@Sun.COM, XACML TC <xacml@lists.oasis-open.org>
 > Subject: RE: [xacml] XACML TC position on SAML Attribute meta-data
 > Date: Wed, 07 Apr 2004 11:01:05 -0700
 > 
 > 
 > 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.
 > 

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