OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




Tech Rams wrote on 8/31/2005, 5:07 PM:

 > I have one doubt...
 > this requirement could used in one of two cases
 > 1. across wsse:security headers
 > 2. within one wsse:security header
 >
 > In case of 1, I am not sure about the wisdom of cross
 > referencing as security headers could potentially be
 > deleted as they are processed.
 > In case of 2, it means that a particular security
 > header is being updated by different entities - which
 > again I am not sure is a good idea.

Our intended use is outside of wsse:Security, but in an
area that is related -- a response from a service that
includes security tokens for different service invocation
endpoints that may use the same token.  So we wanted
to reuse the STR to embed a token in the response and
to allow another portion of the response to refer to
the STR with the embedded token.

Our intended use aside, I think that the TC should
take from this discussion that the language in this
area is *not* as clear as some think.  I'm not the
only one who read the spec and didn't see a restriction
on using an STR to refer to another STR.

So if the WSS really believes that the current document
forbids an STR from referring to an STR, then a
statement along the lines of "A SecurityTokenReference
MUST NOT reference another SecurityTokenReference" should
be added.

If the WSS also wanted to support our intended usage,
the statement could be loosened a bit to say: "STRs
appearing in a wsse:Security header MUST not
reference another STR".

Conor




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]