[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] NameID and the use of SPProvidedID
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 From: Thomas
Wisniewski [mailto:Thomas.Wisniewski@entrust.com] 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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]