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:]
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" <>
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:]
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
