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

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

wss message