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