Re: [wss-comment] recursive Security Token References

[Jeff Hodges <Jeff.Hodges@neustar.biz>]

Conor P. Cahill wrote:
 > Section 7 of the core specification goes into great details
 > on the concept of Token references, but it does not appear
 > to address the concept of a token reference referencing
 > another token reference (e.g. an indirect reference).
 >
 > I think that at the absolute minimum there should be
 > a statement about this case, perhaps saying it is out
 > of scope for the specification

Agreed.

The first sentence of section 7.2 of [1][2] lacks any unambiguous "MUST"-, 
"SHOULD"-, or "MAY"-based statements with regards to what is actually *pointed 
to* (the referent) by a (<wsse:SecurityTokenReference> element containing a) 
<wsse:Reference> element.

[1] oasis-200401-wss-soap-message-security-1.0.pdf
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[2] wss-v1.1-spec-pr-SOAPMessageSecurity-01.pdf
http://www.oasis-open.org/committees/download.php/13397/wss-v1.1-spec-pr-SOAPMessageSecurity-01.pdf



 > My recommendation would be add some discussion within
 > section 7.2 (Direct References) pointing out that such
 > a reference could be a reference to another STR which
 > should be de-referenced.

agreed this should be done if WSSv1.1 "core" were to explicitly support 
STR->STR referencing.



 > We have found a need to refer to a reference in the
 > case where we have messages that may pass round the
 > same token in multiple locations within a message
 > and the ability to refer to the other location is
 > very useful -- especially in the case where one
 > of the STRs is an embedded token and other STRs
 > refer to the embedded token itself.

If WSSv1.1 does not support STR->STR referencing, then others, who have the 
need to have a "security token" container that can either contain either 
contain a security token or reference another container that does contain a 
security token, will be forced to craft their own such container.

 From an industry-wide perspective, it would be unfortunate to have to 
re-invent the wheel when re-use would ostensibly contribute to reducing overall 
fragmentation.

JeffH