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

["Philpott, Robert" <rphilpott@rsasecurity.com>]

I'm not (yet) very comfortable with this change.  

The SAML-defined AssertionID, RequestID, etc. are of type saml:IDType, which
is, of course, of type xsd:string. On the surface, further restricting them
doesn't seem like a huge deal.

While specific mechanisms are left to implementation, the spec does,
however, provide clear guidance on how to ensure the uniqueness of these
ID's. The current suggestion is to perform a Base64 encoding of a
pseudorandom number with specific randomness characteristics.

This is the mechanism we employ in our implementation; using a
cryptographic-strength 160-bit PRN that's Base64 encoded.  So clearly, the
Base64 encoding will cause us problems and thus our IDType generation code
would have to be changed.  Sure, we could hack it by prepending a valid
xsd:ID starting character(s) (e.g. "_", "ID"), but that seems a bit hackish.


I'm not saying we can't do it since it would probably be a relatively minor
code change.  But I want to evaluate the strength of my gag reflex before
agreeing to the proposal.

Is the proposal to completely remove the IDType and IDReferenceType simple
types?  If so, that's a bit more invasive change to the specs and schema. 

Or can it/will it be done by redefining these simple types?

We also need to consider that this change will possibly impact some Liberty
implementations.  All of those implementers are probably not covered by
checking with the saml-dev list?

Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 


> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Tuesday, April 15, 2003 12:59 PM
> 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?
> 
> Thanks,
> 
> 	Eve
> --
> Eve Maler                                        +1 781 442 3190
> Sun Microsystems                            cell +1 781 354 9441
> Web Technologies and Standards               eve.maler @ sun.com