Re: [wss] Issue 250: ValueType --> TokenType+ReferenceType?

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

DeMartini, Thomas wrote:

>It is my understanding that in 310 we would be allowing multiple STRs in
>one KeyInfo.  Certainly I would not have agreed to put multiple
>references within an STR.  In fact, doing so would completely invalidate
>the saml tp.
>  
>
We are getting a bit off the track here, why does it make a difference 
wrt to invalidating
whatever profile, whether we expect them to be be aware of the potential 
for multiple
STR's in keyInfo, or multiple reference forms within STRs?

One benefit of multiple reference forms in STR's, is that it allows for 
alternate references
wherever STR's can be used. Not just in keyInfo.

>If I remember correctly, a person working on saml 2.0 told the tc that
>it uses a different type of assertion id attribute from saml 1.1.  As
>such, I don't see how the method of dereferencing the assertion can
>remain unchanged across the versions.  Certainly it is no problem to
>define another ValueType for KeyIdentifier to represent the saml 2.0
>dereferencing method.
>  
>
The name of assertion ID attribute has changed in 2.0, but in both 
versions the form of the
identifier is an assertion id, and the value of the keyIdentfier would 
be the assertion identfier.
In the case of local references by assertion ID, the wss implementation 
would have to map the
value to the correct attribute. In the case of remote references, this 
distinction could be buried
in the implementation of the assertion authority.

The intent of the example was to show that with the current scheme we 
are forced to create
new keyIdentfier values when we need to differentiate tokens including 
by version, even if the
identifer values and what they represent has not changed or is not 
significantly different.

Ron

>&Thomas.
>
>  
>