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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: RE: [saml-dev] Seeking clarification of Name ID Management Profile

> 1.	Is the Name Identifier Management profile meant to 
> support all Name ID Formats (barring transient, which is 
> forbidden due to its one time use definition)?  I suspect 
> that this is true, but is difficult to confirm based on the 
> following inconsistencies:

Yes, it doesn't matter what the format is, apart from the outlier.

> 	a.	Section 4.5 of saml-profiles-2.0-os.pdf states 
> ".an identity provider has exchanged some form of persistent 
> identifier for a principal.".  Initially I took this to mean 
> "a Name Identifier with a Format of 
> urn:oasis:names:tc:SAML:2.0:nameid-format:persistent".

Poor choice of words, but nobody could agree to just use the word
"federated" for the format name, so we got stuck with a word that also is
the only good adjective to use in profiles. We should change profiles to
something more awkward but non-colliding, like "long term".

> This was partially corroborated by the definition of the 
> persistent identifier in section 8.3.7 of 
> saml-core-2.0-os.pdf, which states one line 3333:  "The 
> element's SPProvidedID attribute MUST contain the alternative 
> identifier of the principal most recently set by the service 
> provider or affiliation, if any.  If no such identifier has 
> been established, then the attribute MUST be omitted."  The 
> other Name Identifier Format definitions do not state this, 
> so it would seem this was the only supported Format.

That's also probably a mistake. The SPProvidedID feature really has nothing
to do with the persistent format, it can apply to any long term format.

> 3.	Does SPProvidedID specify an alias for "this principal" 
> or "this NameID"?

NameID. The other interpretation is too broad for the spec, since it implies
knowledge at the IdP of all the possible ways to refer to a principal.

> I'm trying to determine if there is any 
> impact if the Name ID happens to be common to a group (and is 
> therefore used by multiple users - similar to an 
> Affiliation), and the user is moved from one group to 
> another.  Is the Name ID supposed to follow the user?  I'll 
> admit this is may be a somewhat remote use case.

It definitely wouldn't follow, but that's not really what I was getting
at...I mean it doesn't apply to each of the formats I might be able to go by
as a user (email, Kerberos, persisten, DN). It just attaches to the
particular representation in use.

> 	a.	I saw an item on the security-services mail 
> list that stated that "this NameID" was the original intent, 
> but the text in the specifications still says "this 
> principal".

I thought we had an errata there, but I'm not finding it.

> I see the impact of this as being truly 
> different.  If a SPProvidedID maps to the user, and the user 
> is part of a group or affiliation, and then the user switches 
> groups, what would the behavior be?

You're out of scope, there are no such thing in SAML. Affiliations are not
what you're talking about.

> 4.	Is support for SPProvidedID really a MUST?  Some state 
> for this must be maintained?

It's a MUST for conformance. Beyond that, it's only required that you do
what the messages ask or return an error.
> 	a.	This could require additional per-SP 
> persistence per NameID and/or per principal (depending on the 
> answer to #3) on the IdP for maintaining state.

Supporting it for one format already does, and since all the formats are
MTI, it doesn't really matter from a conformance point of view.

> 	b.	The wording in the specifications (and the 
> errata) in regards to Termination reads something along the 
> lines of "If the provider is maintaining state.", which could 
> be interpreted as either "in the case with SPProvidedID was 
> used in a <ManageNameIDRequest> from the SP" or "if support 
> was implemented".

That's a conformance issue. If you choose not to be conformant, than you're
off the hook. But you also need to be looking at the errata here, because I
know that wording was adjusted a bit when the AllowCreate issues came up.
There isn't much in errata pertaining to your questions, but always look
there first. I wish there was a red line spec, but there's not.

-- Scott

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