[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
You are right. Ideally, the name structure should be compatible without any mangling required. But if we are to consider any particular name parts to be separated (such as the scope), we should communicate that to the SAML community. I suggest that we do consider. (My personal preference is to have the name of an attribute to consist of an URL scope/source and string identifier. With Subject/Resource etc. being a mandatory defined instance of such a scope.) BTW: I did not understand completely: how are SAML attributes mapped into our existing attribute divisions? Daniel. -----Original Message----- From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] Sent: Wednesday, April 07, 2004 11:51 AM To: Daniel Engovatov Cc: XACML TC Subject: RE: [xacml] XACML TC position on SAML Attribute meta-data 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]