OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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