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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

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

Couple questions that may help us (and others) respond:

1) I believe xsd:ID is free form but its char set is more restricted than
xsd:string?  How much more restricted is it?  (I know I could look this up!)

2) Would this incompatibility have any practical impact to a SAMLv1.0
implementation that does not perform schema validation?

-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Tuesday, April 15, 2003 11:59 AM
To: saml-dev@lists.oasis-open.org
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?


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]