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

I concur with Tom’s interpretation as well.  Once an SP uses an MNI to establish an SPProvidedID, then BOTH parties must always send it.  It is not just something that the IDP has to send back.

 

Rob Philpott
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
Email:
rphilpott@rsasecurity.com
I-name:  =Rob.Philpott


From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com]
Sent: Thursday, June 22, 2006 10:31 AM
To: 'SSTC WG'
Subject: RE: [security-services] NameID and the use of SPProvidedID

 

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]