[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] SAML Issuer changes
On 9 March, Seth Proctor writes: Re: [xacml] SAML Issuer changes > On Tue, 2004-03-09 at 12:07, Anne Anderson wrote: > > The current SAML 2.0 draft defines the Issuer element in an > > Assertion as being of NameIdentifierType. Previously it was > > "xsi:string". > > [...] > > > > I suggest we add an optional IssuerFormat XML attribute to our > > AttributeType as follows: > > > > <xs:complexType name="AttributeType"> > > <xs:sequence> > > <xs:element ref="xacml-context:AttributeValue"/> > > </xs:sequence> > > <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> > > <xs:attribute name="DataType" type="xs:anyURI" use="required"/> > > <xs:attribute name="Issuer" type="xs:string" use="optional"/> > > <xs:attribute name="IssuerFormat" type="xs:anyURI" use="optional"/> > > <xs:attribute name="IssueInstant" type="xs:dateTime" use="optional"/> > > </xs:complexType> > > I'm not really sure what use this is to XACML. The only place that the > issuer gets used is when a designator or selector wants to (optionally) > require a particular issuer. This is done via a simple string > comparison. Are you suggesting that the IssuerFormat would somehow be > used in this comparison, or is this useful for something else? If you > want to use the IssuerFormat in this retrieval comparison, then you > probably also have to change designators and selectors to specify this > information, and reject formats that don't match (ie, when the Attribute > uses one format and the designator/selector uses another). We'll also > need to define standard format types and how comparisons work (or at > least reference those in SAML or some other standard). This is a lot of > work, and a fair change to how XACML works today. > > Is this what you had in mind, or was there a different use-case to > support your proposed change? Could you provide some specific details > about why this change would be useful? Yes, I intend IssuerFormat to be optionally specified in AttributeDesignators as well as in Attribute. In general, along with the previous e-mail about SAML allowing arbitrary XML attributes in an Attribute, I'm proposing we generalize the AttributeDesignator selection mechanism: Attributes will be allowed to have arbitrary XML attributes, although AttributeId and DataType will be required. AttributeDesignators will be allowed to have arbitrary XML attributes, although AttributeId and Datatype will be required. All XML attributes in an AttributeDesignator MUST occur in and match using string-match in an Attribute in order for the Attribute to be selected by that AttributeDesignator. An Attribute MAY have more XML attributes than the AttributeDesignator that selects it. This is the same match algorithm we use now; I'm just saying it can be applied using more XML attributes. Why useful? 1. Allows XACML to fully support SAML 2.0 Attributes, with no special casing or extensions needed. 2. Allows XACML to distinguish between two Issuers whose names may match as strings, but whose names are actually of different datatypes. 3. Allows XACML to require that an Issuer name be of a particular datatypes. Drawbacks: 1. Might be a kitchen sink. 2. By not using the match semantics of IssuerFormat in comparing the two string Issuer names, we will have some false negatives (e.g. "Anne@SUN.COM" will not match "Anne@sun.com"). But this is already the case; if false negatives is an issue for us, then we could specify that the match on Issuer name be done using the NameFormat datatype-match function. Now NameFormat buys us even more. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]