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

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

] In our discussions of issue 310, we are considering adding support for
] multiple reference elements
] (of different types) within a single STR. IF we do this, it would seem
] like representing the type of
] the referenced token, in one place, above the alternative references,
] would free us from having to
] ensure consistency among the various reference polluted type values.

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.

] >specific example of a situation we want to accommodate that cannot be
] >accommodated with the current approach.  For example, I get a sense
from
] >reading issue 250 that there is a concern that there might be a
specific
] >type of keyidentifier that could resolve to any type of token and
that,
] >in that case, the ability to "incidentally speak about the type of
token
] >by way of what can be expected based on the specific type of
] >keyidentifier" is not sufficient.  Is this correct?  If so, what
] >
] not yet, but with the current schema, it is unlikely that that could
be
] the case.
] 
] Another dimension to token type is token version. For example, with
the
] current scheme,
] a keyIdentfier based lookup of a version 1.1 saml  assertion would
] represent both that the
] identifier is an asertion id, and that the the type of the referenced
] token is a saml 1.1 assertion.
] Support for 2.0 assertions would require a new keyIdentfier type
value,
] even  though/if the
] method of deferencing the assertion has remained unchanged across the
] versions.

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.

&Thomas.