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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Options for change


I don't understand the statement being made. 

This is not defining a SAML extension mechanism, it is defining the SAML use
of the XML Schema extension mechanism.

Given the confusion that occurred on the focus group call it is clear that
the current situation is not satisfactory for the reasons articulated on the
call.

If the overriding priority is speed then the quickest way to resolve the
issue is to add the slots and if they are superfluous they won't get used. 

The current treatment of attribute values is a little wierd. We require them
to be specified but we don't specify any schema whatsoever.


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: David Orchard [mailto:david.orchard@bea.com]
> Sent: Tuesday, October 02, 2001 4:09 PM
> To: Hallam-Baker, Phillip; Security-Services (E-mail)
> Subject: Re: Options for change
> 
> 
> Seems to me that use of XML Schema extension is exactly what 
> SAML should 
> use.  Creating a new type of extension mechanism is re-inventing the 
> wheel.    Surely SAML 1.0 can be successful without defining 
> SAML data 
> types and extension mechanisms.  Note that I'm not 
> disagreeing with the 
> problem/issues, just with the prioritization of the issue.
> 
> I posit saml 1.0 could be very successful with the existing 
> attributevaluetype.  Let's close the issue and publish the 
> spec a little 
> earlier.
> 
> Cheers,
> Dave
> 
> At 12:06 PM 10/2/01 -0700, Hallam-Baker, Phillip wrote:
> >Existing
> >
> ><complexType name="AttributeValueType">
> >         <sequence>
> >                 <any namespace="##any" 
> processContents="lax" minOccurs="0"
> >maxOccurs="unbounded"/>
> >         </sequence>
> ></complexType>
> >
> >The problem with this set up is that every application 
> requires an extension
> >schema to use an attribute statement.
> >
> >
> >
> >With Generic Data Slots:
> >
> >
> ><complexType name="AttributeValueType">
> >         <sequence>
> >                 <any namespace="##any" 
> processContents="lax" minOccurs="0"
> >maxOccurs="unbounded"/>
> >                 <element ref="saml:BooleanData" minOccurs=0
> >maxOccurs="unbounded"/>
> >                 <element ref="saml:IntegerData" minOccurs=0
> >maxOccurs="unbounded"/>
> >                 <element ref="saml:BooleanData" minOccurs=0
> >maxOccurs="unbounded"/>
> >         </sequence>
> ></complexType>
> ><element name="BooleanData" type="boolean"/>
> ><element name="IntegerData" type="integer"/>
> ><element name="StringData" type="string"/>
> >
> >
> >Using generic slots the namespace can specify the use of the 
> slot, for
> >example:
> >
> ><AttributeValue Namespace="urn:whatever:academic-agreement-2001"
> >         Name="MemberOfFaculty">
> >    <StringData>MIT.EDU</StringData>
> ></AttributeValue>
> >
> ><AttributeValue Namespace="urn:whatever:academic-agreement-2001"
> >         Name="IsA Student">
> >    <BooleanData>true</BooleanData>
> ></AttributeValue>
> >
> >
> >This leave the problem that the attribute slot is intended 
> to be extensible
> >but an extension schema can't declare an extension that is 
> only for use as
> >an attribute value.
> >
> >With generic data slots and an extension point:
> >
> >
> ><complexType name="AttributeValueType">
> >         <sequence>
> >                 <any namespace="##any" 
> processContents="lax" minOccurs="0"
> >maxOccurs="unbounded"/>
> >                 <element ref="saml:AttributeElement"/>
> >                 <element ref="saml:BooleanData" minOccurs=0
> >maxOccurs="unbounded"/>
> >                 <element ref="saml:IntegerData" minOccurs=0
> >maxOccurs="unbounded"/>
> >                 <element ref="saml:BooleanData" minOccurs=0
> >maxOccurs="unbounded"/>
> >         </sequence>
> ></complexType>
> ><element name="AttributeElement" type="saml:AttributeElementType"/>
> ><complexType name="AttributeElementType"/>
> >
> >
> >Phillip Hallam-Baker FBCS C.Eng.
> >Principal Scientist
> >VeriSign Inc.
> >pbaker@verisign.com
> >781 245 6996 x227
> >
> 

Phillip Hallam-Baker (E-mail).vcf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC