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:]
Sent: Tuesday, April 15, 2003 11:59 AM
To:
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
