atom feed13 messages in org.oasis-open.lists.imiRE: [imi] RE: Proposed claim encoding...
FromSent OnAttachments
Mike JonesAug 27, 2009 8:06 am.doc
Anthony NadalinAug 28, 2009 10:10 am 
Scott CantorAug 28, 2009 10:25 am 
John BradleyAug 28, 2009 12:26 pm 
Anthony NadalinAug 31, 2009 9:18 am 
John BradleyAug 31, 2009 9:38 am 
Mike JonesAug 31, 2009 10:22 am 
Anthony NadalinAug 31, 2009 10:37 am 
John BradleyAug 31, 2009 10:52 am 
John BradleyAug 31, 2009 11:02 am 
Mike JonesSep 3, 2009 3:56 pm 
John BradleySep 3, 2009 4:11 pm 
Mike JonesSep 17, 2009 8:21 am 
Subject:RE: [imi] RE: Proposed claim encoding profile for SAML 1.1 tokens
From:Anthony Nadalin (tony@microsoft.com)
Date:Aug 31, 2009 10:37:56 am
List:org.oasis-open.lists.imi

Well not sure that the IMI spec actually points that out (could not find it),
also the IMI spec only deals with personal cards. Many folks end UIRs with a "/"
just go and look at various postings, may not be right but this stuff happens
and ignoring it does no good

From: Mike Jones Sent: Monday, August 31, 2009 10:23 AM To: John Bradley; Anthony Nadalin Cc: im@lists.oasis-open.org Subject: RE: [imi] RE: Proposed claim encoding profile for SAML 1.1 tokens

We made it clear both during the OSIS tests and in the IMI spec that claim names
are to be matched as-is, with no case folding, normalization, etc. John's right
- trying to "fix things" for people usually makes things worse.

In practice, I'm not aware of any claim URIs that end with a slash, so I don't
see this as being a big problem. Are any of you aware of any? (It probably is
worth figuring out how to best encode such claims if they do arise. Suggesting
the use of the urn:oasis:names:tc:SAML:2.0:attrname-format:uri convention is one
possibility, since these are not "normal" claim URLs.

-- Mike

From: John Bradley [mailto:jbra@mac.com] Sent: Monday, August 31, 2009 9:38 AM To: Anthony Nadalin Cc: Mike Jones; im@lists.oasis-open.org Subject: Re: [imi] RE: Proposed claim encoding profile for SAML 1.1 tokens

The ida is to keep it consistent with the p-cards.

That is an interesting question.

Do the selectors all recognize the p-card claims with or without the "/". I know they do without.

What the selector matches, is it normalized? Given that the selector copies the claims from the RP's policy directly. (this
is fudged for the object tag ver) The selector probably shouldn't modify the requested URI.

What should the matching rules be for a IP/STS?

Should both the p-card and IP STS normalize assertions to remove trailing "/".

In some ways my preference is to not mess with it too much.

A claim is an opaque URI (except for the bit where it isn't) if the RP adds
trailing "/" then they shouldn't match unless the actual claim has a trailing
"/".

Trying to automatically fix things for people leads to HTML.

John B.

On 31-Aug-09, at 12:18 PM, Anthony Nadalin wrote:

Yea it's those nasty shares that I have to mount here:). I agree with the SAML
1.1 Managed cards, I assumed that this would apply to both managed and
non-managed cards. My point is that we have seen some with the trailing "/" and
some w/o and this needs to be clarified.

From: John Bradley [mailto:jbra@mac.com] Sent: Friday, August 28, 2009 12:26 PM To: Anthony Nadalin Cc: Mike Jones; im@lists.oasis-open.org<mailto:im@lists.oasis-open.org> Subject: Re: [imi] RE: Proposed claim encoding profile for SAML 1.1 tokens

At the moment we have nothing for SAML 1.1 managed cards.

That is an even bigger potential interoperability issue.

This at least gives us something to discuss.

I am guessing that you mean "/" as a terminating character. This MS gig has
really gotten to you.

None of the claims in the ICF catalog have trailing "/" nor do the p-card claims
eg http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

If you are under some different impression that makes documenting this more
important.

I would be OK with just documenting the current behavior based on the p-card
STS. We could say the SAML 1.1 profile only supports http scheme URI that have one or
more one path segments.

That is basically where we are anyway. Less code to rewrite for MS.

People who need more functionality should use the SAML 2.0 profile.

Fixing IMI SAML 1.1 code to deal with URNs and other things may not be worth
the effort.

We do however need something written down!

John B.

On 28-Aug-09, at 1:10 PM, Anthony Nadalin wrote:

I think there are a few problems, as it does not explicitly state that the "\"
at the end is required. Also the language is too laxed for interoperability,
this seems to be caused by the desire to have some level of co-existence with
the SAML 2.0 profile, which may not be the best thing to do

From: Mike Jones [mailto:Mich@microsoft.com] Sent: Thursday, August 27, 2009 8:07 AM To: im@lists.oasis-open.org<mailto:im@lists.oasis-open.org> Subject: [imi] Proposed claim encoding profile for SAML 1.1 tokens

I've run the attached proposed claim encoding profile for SAML 1.1 tokens by
John and Drummond, as well as Paul Trevithick. I believe it does what we need
(while still being a one-pager). It's intended to maximize interoperability.

This issue is tracked as IMI-23.

-- Mike