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

[Greg Whitehead <grw@trustgenix.com>]

On Jul 14, 2004, at 2:02 PM, Ron Monzillo wrote:

>
>
> 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.

Ok, if you're talking about re-defining and re-naming Embedded to 
something else that can be used outside of a STR (providing a place to 
add a WSS-compatible id attribute), that's fine. I was simply pointing 
out that Embedded, in it's current state, does not serve that purpose.

> 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.

Well, I would agree with you if WSS could use any IDType attribute. 
Sadly, it looks like that's not possible. If we could migrate from the 
IDType standard mechanism to some other standard mechanism like xml:id, 
that would be fine. I'm a little uncomfortable adopting wsu:Id as our 
native id mechanism and even less comfortable trying to support a 
choice between multiple id mechanisms. As lousy as wrappers might be, 
they're better than introducing this complexity into our schema.

> 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.

If it's a moving target, even more reason to insulate ourselves from it 
for the time being, don't you think?

> 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.

If we could use our native identifier in a direct reference, that would 
be great, but I thought that was the problem.

> 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).

How would KeyIdentifier work? If you mean that we can just define our 
own STR mechanism that works with our ID, that sounds best, but I 
didn't think that was an option.

-Greg