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

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

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

Because the saml tp already utilizes the multiple children aspect of STR
to carry the saml:AuthorityBinding together with the wsse:KeyIdentifier,
overloading the semantics of those multiple children of an STR to mean
multiple equivalent references would create a normative conflict.

You are right, though, this is getting off track.  There are also other
good reasons the tc decided to go with multiple STRs in a KeyInfo, and I
did not mean to reopen issue 310; I just meant to point out it is not
relevant to this discussion.

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

&Thomas.