OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

imi-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [imi-comment] Re: comments on SAML V2.0 Information Card Token Profile Version 1.0


Thanks for the clarifications.
I have updated the STS of the www.cardgears.com service accordingly.
It should now be compliant with the SAML 1.1 and SAML 2.0 token profiles..

Markus

On Wed, Jun 23, 2010 at 2:54 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for your comments, Markus. The resolutions taken to them are as follows:

Comment #1 issue IMI-36.

We made the proposed correction. See http://www.oasis-open.org/committees/download.php/38404/imi-saml2.0-profile-ed-07.doc for a corrected version.

Comment #2 issue IMI-37.

The consensus during 4/15 call was that the existing text mentions proxies and is sufficient to explain the problem. No change was made.

Comment #3 issue IMI-38.

The particular usage mentioned is the KeyIdentifier ValueType to be used, which should be handled per the WS-Security SAML Token Profile (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SAMLTokenProfile.pdf)

Per that profile, in section 3.4, the ValueType constants for KeyIdentifier are:

V1.1 http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID
V2.0 http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID

Other constants may be applicable in other spots, for example the wsse11:TokenType in an STR. All these constants are orthogonal to the token type being referenced at the WS-Trust exchange layer, which is the only usage we're dealing with in the IMI token profiles.

The consensus during 4/15 call was that no change to the profiles is needed.

Comment #4 issue IMI-39.

While this may be a good suggestion, it's not relevant to the token profiles but could be raised against the IMI standard itself as a suggested change. No change was made to the profiles.

-- Mike

From: Markus Sabadello [mailto:markus.sabadello@gmail.com]
Sent: Thursday, April 08, 2010 1:12 PM
To: imi-comment@lists.oasis-open.org
Subject: [imi-comment] Re: comments on SAML V2.0 Information Card Token Profile Version 1.0

Comment #4:

It seems that with every new token profile that gets added to IMI, all already existing cards need to be reissued, because the supported token types are listed in the .crd file. Maybe it would be better to remove SupportedTokenTypeList from the .crd files and instead let selectors ask the Metadata endpoint. This way STSes can over time add support for new token types even for already existing cards.

Markus

On Thu, Apr 8, 2010 at 12:10 AM, Markus Sabadello <markus.sabadello@gmail.com> wrote:

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]