Re: [wss] RE: [wss-comment] recursive Security Token References

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

DeMartini, Thomas wrote:
 > So, if we edited 903-904 as follows (removing things in {} and adding
 > things in []), would the new words be sufficiently unambiguous?
 >
 > "This optional attribute specifies an abstract URI for {where to find} a
 > security token. If a fragment is specified, then it indicates the local
 > ID of the [security] token being referenced. [The URI MUST identify a
 > security token.  The URI MUST NOT identify a wsse:SecurityTokenReference
 > element, a wsse:Embedded element, a wsse:Reference element, or a
 > wsse:KeyIdentifier element.]"


Let's see, applying the transform to make it easier to read, yields...


    This optional attribute specifies an abstract URI for a
    security token. If a fragment is specified, then it indicates the local
    ID of the security token being referenced. The URI MUST identify a
    security token.  The URI MUST NOT identify a wsse:SecurityTokenReference
    element, a wsse:Embedded element, a wsse:Reference element, or a
    wsse:KeyIdentifier element.


Yes, I believe that statement itself is sufficiently unambiguous, thanks.

A subtle-but-important wrinkle behind this, though, that I noticed in reading 
thru the spec with the above security token reference restrictions in mind, is: 
there is not, in the spec, what I consider a concise definition of what 
precisely constitutes a "security token".

I presume, for example, that we consider <wsse:BinarySecurityToken>, along with 
anything it might contain, to be a "security token". The same for 
<wsse:UsernameToken>. And thus it is ok, per the restriction above, for an STR 
to reference them, yes?

JeffH