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

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

Thomas,

This msg is in response to the issue 310 related aspect of this thread.

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.
>
>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.
>
The STP currently requires that a keyIdentifier be used in an STR, that 
it take a specific
form, and that it be supported by an AuthorityBinding element if the 
token is remote.

These requirements do not preclude the inclusion of other/optional 
reference forms in an STR that
references a SAML token.

For example an STR could include a keyIdentifer with a supporting 
AuthorityBinding
element, and a Direct reference with a contained URL.

The optional inclusion of a direct reference  in addition to the 
required keyIdentifer, would parrallel
my suggestion that we allow the optional inclusion of thumbprint based 
KIDs in addition to a
required to be supported reference form.

In the case of the STP, there will be changes in the permitted reference 
forms (as a result of the update to
1.1 core to allow local direct references by assertion identifier). In 
making those changes it would,
IMV, be appropriate to reword the requirements around keyIdentifiers, 
such that they no longer
preclude the inclusion of other forms of keyIdentifiers in addition to 
the one that implementations
are required to support.

I think all the profiles should be re-released with V1.1 core.

Ron