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] NameID and the use of SPProvidedID


Title: Message
Greg, following your same reasoning of lines 2481-2487 (but applied to the IDP) ... in the case of IDP initiated name change only the SP is called out as having a requirement to send the element's contenct (back to the IDP).
 
But this is clearly not desired -- as you always want the IDP to send its identifier value to bhe SP.
 
Tom.
-----Original Message-----
From: Greg Whitehead [mailto:greg.whitehead@hp.com]
Sent: Thursday, June 22, 2006 12:32 PM
To: Thomas Wisniewski; 'SSTC WG'
Subject: Re: [security-services] NameID and the use of SPProvidedID

Line 2481-2487 seem to clearly separate the cases of SP and IDP initiated name change. Note that in the case of SP initiated name change only the IDP is called out as having a requirement to send SPProvidedID (back to the SP).

I read the text on lines 2490-2492 as saying that when a NameID and it's associated SPProvidedID are included in a request (subject to the text in lines 2481-2487), it MUST be the most current value.

This reading would be consistent with the way things were done in IDFF, which is probably why I'm biased in that direction. I also prefer this interpretation because there's no utility in sending SPProvidedID back to the IDP.

In any case, the most important thing is to reach consensus and clarify things in errata.

-Greg


On 6/22/06 9:31 AM, "Thomas Wisniewski" <Thomas.Wisniewski@entrust.com> wrote:

Greg, Scott, Conor, I'm going through this one again, and I want to bring up the issue again -- I don't agree with your interpretation of the current specs.

 
When I read the Core specs (2433-2438 and 2490-2492 -- quoted below), it seems obvious that the spec forces the SP, once it sets the SPProvidedID, to set this value in all subsequent messages to the IDP. This is a MUST requirement for the SP.

The main stmt being line 2490-2492
"In any case, the <saml:NameID> content in the request and its asociated SPProvidedID attribute MUST contain the most recent name identifier information established between the providers for the principal."

I do believe my interpretation of the specs is the correct one. Otherwise what is the purpose of the above statement? If you don't agree, please advise how you interpret the above statement.

 

Having said that, the actual intent (potential for errata) can be argued as well.

If we say that the SP can arbitrarily include the new SPProvidedID or omit it, what stops us from saying that once the IDP changes its identifier using a <NewID> MNI call, it too does *not* have to include that value. If this is the case, then all things can bread down if the SP decided to "remove" (use a blank) its value as now the IDP would not have to send anything to the SP ...

It just seems wrong that we have defined a pair-wise identifier, and the SP can arbitrarily send its identifier (so it only needs to send one value in the pair) to the IDP while the IDP must send the pairwise identifier. If the SP wants to set the SPProvidedID, then it should be held to that identifier in future calls to the IDP (just as when the IDP changes its identifier, it is held to sending its identifier in calls to the SP).

Tom.

 

 
-----Original Message-----
From: Thomas  Wisniewski [mailto:Thomas.Wisniewski@entrust.com]
Sent: Friday,  June 09, 2006 11:17 AM
To: 'SSTC WG'
Subject:  [security-services] NameID and the use of SPProvidedID


All, there is  some contention around the interpretation of SamlCore lines 2433 - 2438 and  2490 - 2492.

 

"The new identifier  value (in plaintext or encrypted form) to be used when communicating with the  requesting provider concerning this principal, or an indication that the use of the old identifier  has been terminated. In the former  case, if the requester is the service provider, the new identifier MUST appear  in subsequent <NameID> elements in the SPProvidedID attribute. If the  requester is the  identity  provider, the new value will appear in subsequent <NameID> elements as the element's  content."
 

...
 

"In any case, the  <saml:NameID> content in the request and its asociated SPProvidedID  attribute MUST contain the most recent name identifier information established  between the providers for the principal."
 

This has to do with setting the  persistent NameID value using the NewID option of an MNI  request.
 

Assume original  NameID is as follows:


<NameID  NameQualifier="idp" SPNameQualifier="sp"  Format="...persistent">abcd</NameID>


Assume that an SP sets  their SPProvidedID to "1234". It is clear that  the IDP, upon accepting the new value MUST send any references to this NameID  such that the SPProvidedID is specified to "1234"
 

So an IDP would  send
 

<NameID  NameQualifier="idp" SPNameQualifier="sp" Format="...persistent"  SPProvidedID="1234">abcd</NameID>


Now  consider  if the SP needs to intiate an request (e.g., Single Logout). I would content  that the SP MUST send the following as well:


<NameID  NameQualifier="idp" SPNameQualifier="sp" Format="...persistent"  SPProvidedID="1234">abcd</NameID>


Another interpretation is that the SP is allowed to  continue to send:
 

<NameID  NameQualifier="idp" SPNameQualifier="sp"  Format="...persistent">abcd</NameID>
 

I.e., it never needs to send the value it set in  its MNI request that  with NewID="1234".


Tom.
 

Thomas Wisniewski
Software Architect

Phone: (201)  891-0524
Cell: (201) 248-3668  

EntrustÒ
Securing Digital Identities
& Information


 




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