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: Re: [security-services] NameID and the use of SPProvidedID
No, I think lines 2490-2492 are clear that if the value of NameID is included it must hold the latest value.

-Greg


On 6/22/06 12:50 PM, "Thomas Wisniewski" <Thomas.Wisniewski@entrust.com> wrote:

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]