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

["Jeff Bohren" <jbohren@opennetwork.com>]

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