Re: [wss] STR Transform Algorithm summary, questions

[Jerry Schwarz <jerry.schwarz@oracle.com>]

At 11:22 AM 02/25/2003, Frederick.Hirsch@nokia.com wrote:
>We had a discussion on the call today regarding the STR transform,
>here is my attempt to summarize the discussion
>
>Can either sign a STR or use an STR to locate what is to be signed.
>
>1. Goal: Sign SecurityTokenReference
>Technique: SignedInfo <ds:Reference> can reference id of 
>SecurityTokenReference directly.
>No use of STR transform.
>
>2. Goal: Include what SecurityTokenReference points to in signature
>Technique: STR Transform points to SecurityTokenReference located in 
>Security header, SignatureProperties element
>or elsewhere. Processing rules corresponding to Transform algorithm URI 
>require SecurityTokenReference be
>located and "dereferenced" to located corresponding token. The octets 
>corresponding to the token are used to
>create the ds:Reference hash. Algorithm is identified as 
>http://schemas.xmlsoap.org/2002/xx/STR-Transform
>
>Goal: Dereferencing a SecurityTokenReference
>1. Direct reference - dereference to obtain SecurityToken element
>2. KeyIdentifier, KeyName - XKMS locate or other mechanism to obtain 
>corresponding token octets
>3. Inline token - extract inline token (pull out child), octets (convert 
>node set using canonical xml)

In case the reference element is a BinarySecurityToken, I believe 
dereferencing also includes converting to the binary value, but I'm not 
sure about that.

I don't think we've described the rule in the case where the referenced 
element is itself a SecurityTokenReference. Maybe nothing special happens, 
or maybe it's disallowed or maybe dereferencing proceeds recursively. I 
would favor recursion, but I don't care strongly about the answer, but it 
needs to be made clear.

>Question - does a SecurityTokenReference need a type attribute to aid this 
>dereferencing rather than
>requiring examination of the content.

The attribute would be redundant information. That is, it would is 
reduntant with the tag of the subelement.  I don't know whether that would 
be useful or not.

>Is this the Usage attribute?

Definitely not.  The usage attribute says how the referred to token is 
related to the message. The attribute you're talking about is the mechanism 
used to locate the security token.

>If so, should we define these QNames:

No.


>wsse:STR_DirectReference
>wsse:STR_KeyIdentifier
>wsse:STR_KeyName
>wsse:STR_Inline
>
>Another question
>Is an inline security token meant to also have a direct reference and use 
>the inline portion as a cached
>performance improvement or is the only location of the token the inline 
>value ("wrapped"). I presume the
>latter, that each STR is only one type.

I'm not sure I understand this. In the case where the inline security token 
itself has the required form, other references could go either to the STR 
or the inlined token.  I don't see any reason to do this, but I don't see 
any reason to forbid it either and I generally don't like arbitrary 
restrictions.



>regards, Frederick
>
>Frederick Hirsch
>Nokia Mobile Phones
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>