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