Re: [security-services] New Issue: AssertionID/ WSS Direct referencecompatability

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Greg Whitehead wrote:

>
> On Jul 13, 2004, at 3:07 PM, Ron Monzillo wrote:
>
>> There already is such an envelope in WSS
>> but it's use (which causes in-lining) would preclude efficiencies
>> where the same on msg token is used in multiple security opertaions
>> on the msg (i.e. as the KeyInfo of two signatures)
>
>
> The Embedded wrapper is different than what I am proposing -- as you 
> point out, the Embedded wrapper precludes multiple use. What I am 
> proposing is a wrapper that can carry the wsu:Id attribute without 
> creating problems with our own schema, or requiring assertion 
> generators to know a-priori how an assertion will be transported.

I am not a fan of the token wrapping approach, but let me clarify
what I wrote in my previous msg.

WSS already has an STR that can carry an embedded token.
Tokens are embedded in this STR by encapsulating them in an
internal to the STR element called "Embedded".

WSS does not define the use of the "Embedded" element
outside of an STR, and the "Embedded" element would need a
bit of a tuneup to be completely useful as a standalone XML token wrapper.

It is the use of an STR that carries an embedded token that precludes
multiple use of the same instance of the token. Fleshing out the 
semantics of
the "Embedded" element  (and likely renaming it) to serve as a sort of 
universal
token wrapper is what I was describing as the logical place to evolve token
wrapping functionality in WSS.

I think wrapping SHOULD only be necessary for encoded tokens and for
tokens that do not have an identifier attribute. Neither of these concerns
apply to SAML assertions.

The resolution to restrict which id's can be used in a local direct
reference is inspiring convergence on a common but temporary id name, which
itself likely will either need to change in the future, or will become 
unnecessary along
with any encapsulation required to sustain it.

Despite my view that the WSS core should consolidiate on one simpler,
more complete, and  better understood token wrapping mechanism, I do NOT 
think
that profiles of security tokens that do not suffer from either of
the concerns listed above should advocate the use of wrapping mechanisms to
in lieu of being able to use native identfiers in local direct references.

The short term work-around for that problem is to use a KeyIdentifier, 
ultimately
the solution may be to evolve both WSS and the token schema ids to match 
the outcome
of the xml:id activity (which will not require encapsulation).

Ron