comments on SAML V2.0 Information Card Token Profile Version 1.0

[Markus Sabadello <markus.sabadello@gmail.com>]

Comment #1:

It seems the examples in 2.7.1 and 2.7.2 are bugged, because the attributes Address and NotOnOrAfter are put on a SubjectConfirmation element rather than on a SubjectConfirmationDataType element.

Comment #2:

Section 2.6.1 discusses the use of the Address attribute.
"While moderately effective, this practice often proves impractical for services offered to large user populations, many of whom are likely to encounter proxies and network configurations that result in inability to satisfy the restriction"

Just wanted to add as an observation that this is also impractical in situations where a selector relies on a cloud-based service for talking to the STS.
E.g. the iPhone I-Card Selector works like that, therefore the IP address seen by the STS is always different from the IP of the selector.

Comment #3:

RSTRs typically contain something like this to reference the issued security token:

    <RequestedAttachedReference>
        <SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">urn:uuid:992eea3f-08fa-44fb-8b84-8245b122dafc</KeyIdentifier>
        </SecurityTokenReference>
    </RequestedAttachedReference>
    <RequestedUnattachedReference>
        <SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">urn:uuid:992eea3f-08fa-44fb-8b84-8245b122dafc</KeyIdentifier>
        </SecurityTokenReference>
    </RequestedUnattachedReference>

What ValueType should STS implementers use when adopting the recent SAML1.1 and SAML2.0 token profiles? Is this ValueType the same as the wst:TokenType in the RST?

Markus