[wss] STR Transform Algorithm summary, questions

[Frederick.Hirsch@nokia.com]

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)

Question - does a SecurityTokenReference need a type attribute to aid this dereferencing rather than
requiring examination of the content. Is this the Usage attribute? If so, should we define these QNames:

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. 

regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones