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

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

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


Subject: RE: [provision] FW: [saml-dev] Constrain existing ID attributes?


Added to planned agenda.

=========================================================
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
512) 657 8360                     
=========================================================


> -----Original Message-----
> From: Jeff Bohren [mailto:jbohren@opennetwork.com]
> Sent: Thursday, April 17, 2003 9:40 AM
> To: provision@lists.oasis-open.org
> Subject: [provision] FW: [saml-dev] Constrain existing ID attributes?
> 
> There is a proposal in the SAML group to make some of thier ID
elements of
> type xsd:ID instead of string. The advantage is that those IDs can now
be
> used directly in XPath and XML Signatures without having to add a
parallel
> ID via the Open Content Model (which we now support in SPML). I think
it
> will be very useful for us to do the same with our Request ID.
> 
> The only restriction that this imposes is that the request ID conform
to
> the xsd:ID restrictions. That means that the ID must start with an
alpha,
> and the could contain alphanumerics and certain punctuations (".",
"-",
> and "_").
> 
> I would like to add motion for modays meeting to change the type of
the
> Request ID element from xsd:string to xsd:ID.
> 
> Jeff Bohren
> OpenNetwork Technologies
> 
> 
> 
> 	-----Original Message-----
> 	From: Eve L. Maler [mailto:eve.maler@sun.com]
> 	Sent: Tue 4/15/2003 12:58 PM
> 	To: saml-dev@lists.oasis-open.org
> 	Cc:
> 	Subject: [saml-dev] Constrain existing ID attributes?
> 
> 
> 
> 	In SAML V1.0, there are attributes on assertions, requests, and
> 	responses called, respectively, AssertionID, RequestID, and
> ResponseID.
> 	  These attributes have the type xsd:string.
> 
> 	As you have seen in earlier email from Prateek, we have been
> planning to
> 	add parallel ID attributes that are of type xsd:ID, making those
> 	elements suitable as targets of id() XPaths used in XML
Signature.
> The
> 	reason we were planning to add parallel attributes, rather than
> further
> 	constraining the existing attributes by changing their type from
> 	xsd:string type to xsd:ID type, is that this would be a
> 	backwards-incompatible change in a minor SAML revision.
> 
> 	Because of the previous underspecied state of XML Signature and
the
> 	early stage of SAML's development, we're considering bending our
own
> 	backward incompatibility rule and simply constraining the
original
> 	attributes -- and NOT adding the parallel attributes.  This is
> appealing
> 	because it avoids a confusing "merge" process in SAML V2.0 to
> 	reintegrate the two sets of attributes, but it may cause
problems to
> 	implementers who depend on creating AssertionID (etc.) values
that
> 	contain characters not allowed in xsd:ID values.
> 
> 	Can implementers please weigh in and let us know (a) if doing
this
> would
> 	break their current implementations and (b) if so, would it be a
> problem
> 	to update their implementations to account for this in their
SAML
> V1.1 work?
> 
> 	Thanks,
> 
> 	        Eve
> 	--
> 	Eve Maler                                        +1 781 442 3190
> 	Sun Microsystems                            cell +1 781 354 9441
> 	Web Technologies and Standards               eve.maler @ sun.com
> 
> 



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