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

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

I have the same 
understanding.

 

&Thomas.

From: Jeff Hodges 
[mailto:]
Sent: Thu 9/1/2005 6:55 
PM
To: 
Cc: 

Subject: 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