[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]