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

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

DeMartini, Thomas wrote:

>] >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.
>
>As you have just said, in the case of local references by assertion ID,
>the referencing method is version specific; therefore, it is fitting
>that a single URI be used to identify both the token version and
>referencing method.  This is currently the case and is correct.
>
>In the case of remote references, while the distinction could be buried
>in the implementation of the assertion authority, a) the distinction
>still exists while buried and b) the local client still has to look for
>a different namespace in the AuthorityBinding element.
>
>I don't see any downside in creating a new ValueType for keyidentifier
>references for saml 2.0 tokens.
>
>] 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.
>
>I'm not worried about the generic case at the moment.  I'm interested in
>whether there is any specific real example that cannot be accommodated
>in the current scheme.
>
I think you are concerned that augmenting STR's with the inclusion of a
new attribute that identifies the type and perhaps version of the token 
being referenced
(in a manner independent from the type of the reference) will somehow 
invalidate
the existing profiles.

I believe the profiles will be updated and re-released with version 1.1 
of the core.

I am proposing that a new attribute be added to the top level STR 
element, and
that this attribute be used to identify the token type and version

I would prefer that the 1.1 core make this attribute required. I am 
hopeful that you would at
least support its inclusion as RECOMMENDED. In the latter case, 
individual profiles
could specify that they require that this attribute be specified in 
their context.

I'll send a separate message on the part of this thread pertaining to 
issue 310.

Ron

PS: The existing scheme, any processing that is dependent on being able 
to recognize
the token type (or token version), must be modified every time a new 
reference type identifier
is introduced for an existing token type and version.

>&Thomas.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
>
>  
>