[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]