RE: [security-services] New Issue: AssertionID/ WSS Direct referencecompatability

> references. In light of the recent resolution, and to achieve 
> the original
> objective of only using Direct references, SAML 2.0 will need 
> to make it
> at possible to include a wsu:id identifier attribute in a 
> SAML assertion.
> 
> SAML 2.0 should also anticipate future XML standardization of 
> an identity`
> attribute (e.g. xml:id)  as a replacement for wsu:id.
> 
> It has been suggested that the saml:AssertionID be made an optional 
> attribute,
> and that the SAML 2.0 assertion schema be enhanced to allow 
> for attribute
> extensibility.

Of course, you couldn't have both wsu:id and AssertionID attributes on the same Assertion element, since they're both of XML ID-type. And if AssertionID were retained in the SAML schema, but made optional (or, better, a choice vs. wsu:id), then the producer of an Assertion would need to be aware of its potential use as a WSS security token and know to use a wsu:id attribute instead. (A WSS processor could not replace an AssertionID with a wsu:id without breaking the signature on the Assertion.) This coupling between Assertion producers and utilizers seems more than a little ungainly to me, absent a mechanism for alerting the producer in advance to the intended transport context of the Assertion.

::Ari

Ari Kermaier
Oracle Corporation
ID Management & Security Products