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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: RE: [security-services] AuthnRequest Subject vs. NameIDPolicy usage

Title: Message

From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com]
Sent: Friday, June 03, 2005 8:12 AM
Subject: [security-services] AuthnRequest Subject vs. NameIDPolicy usage


All, I'm trying to understand Profiles section (<AuthnRequest> Usage). Specifically the fact that Subject is allowed and how this related to NameIDPolicy.  I assume the reason Subject is allowed is to because the requesting service provider may know the subject's identity and wants the identity provider to match this against the user being authenticated.

[RSP] Basically yes. Note that it can be used when an SP needs to upgrade the authentication level of a user by sending back to an IDP to log in with a “stronger” method.  The IDP then might not require the user to re-enter their user-id when logging in with the stronger method; just the new credentials.


It would seem that this should imply that NameIDPolicy's Format and SPNameQualifier attributes MUST be omitted in this case.

[RSP] Or it could be required that they match. I have to agree that I wouldn’t understand the semantics if they were different.


The AllowCreate attribute could be used as it currently is. Is that the intent?

[RSP] I think so.

If not and both are used such that the Format and/or SPNameQualifier attributes are defined in both (and of course possibily different), what would be the processing rules?


I'm proposing that these two attributes in NameIDPolicy not be used when using Subject.

[RSP] As I said, I think it would also be valid to have them match what’s in the subject.  But I’d agree that is redundant and could live with making the Subject and format/SPNameQualifier mutually exclusive… At least within the web SSO profiles.  I wouldn’t place the rule in Core since someone else may come up with a profile that has different semantics.


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