[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] XACML TC position on SAML Attribute meta-data
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]