Re: [liberty-dev] 2 items for clarification in protocols and schemas document

From “Hubert A. Le Van Gong” <>
Date Mon, 12 Aug 2002 15:57:39 -0700
User-agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408


I think the problem comes from the fact that we should have
<IDPProvidedNameIdentifier> instead of <saml:NameIdentifier>
in the SingleLogoutNotification element.

It could also be <SPProvidedNameIdentifier> if the Registrer
Name Identifier protocol was used prior to logout.

In the 1st case, there should not be any problem as it’s the IdP
itself which generated it: the SPs have to use the very same
identifier, not a truncated version of it (the optional aspect
is just at creation time IMHO): this is a direct consequence
of lines 926-927 (Section 3.3).

In the case where an <SPProvidedNameIdentifier> has been
generated, the IdP should make sure it has a way to uniquely
identify the user (e.g. association between the SP Id and the



——– Original Message ——–

Subject: Re: [liberty-dev] 2 items for clarification in protocols and schemas document
Date: Sun, 11 Aug 2002 21:23:31 -0700
From: Jon Serg <serg@Sun.COM>
References: “>< > <00ea01c241b4$16aab480$560210ac@vineet >


--On Monday, August 12, 2002 9:25 AM +0530 Vineet Arora 
> About the second questoion i am not very sure what the answer is like but
> the answer to the first question according to my understanding is that the
> sender will only include its own specified NameIdentifier for the
> principal to the receiver that is during the maintaining of user mapping
> each of the sender and receiver would have decided on NameIdentifier for
> a principal at the IDP and the SP end .This NameIdentifier will be
> included in the Logout Request.


That wasn't quite the question for #1.  I was assuming that 
RegisterNameIdentifierRequest had not been used.

I was trying to get at this situation in #1...
- IDP returns AuthnResponse to SP, containg NameIdentifier:
- SP does not send RegisterNameIdentifier request (since it is optional).
- SP sends LogoutN
otification to IDP, only sends 
baz, omitting the NameQualifier 
and Format attributes since they are marked as optional in the SAML 
specification.  If the IDP relies on the name qualifier to disambiguate the 
value of the name field, it may not be able to find the user record as a 

To me it makes the most sense to require the SP to include the same 
saml:NameIdentifier element without any changes or omissions to the 
attributes.    But the spec does not explicitly define this; on 
protocols-schemas-v1.0 lines 811 and 863, it is only specified as "the name 
identifier of the Principal...".

Thus my question was really how others trying to implement the protocol 
spec had interpreted this (but I managed to not express that v
ery well late 
on a Friday).  I have run into at least one implementation that interpreted 
this differently than I did, and we couldn't interoperate as a result 
without a workaround.

> ----- Origin
al Message -----
> From: "Jon Serg" 
> To: 
> Sent: Saturday, August 10, 2002 4:30 AM
> Subject: [liberty-dev] 2 items for clarification in protocols and schemas
> document
>> Here are two things in the protocols and schemas document that recently
>> came up for us as potential interoperability problems:
>> (1) In the Single Logout protocol, the specification doesn't seem to
>>     explicitly say whether the sender needs to include the entire
>>     NameIdentifier that was sent in the Assertion (or possibly
>>     RegisterNameIdentifierRequest), or just the mandatory value.  The
>>     qualifier and format are optional.
>>     It seems to me that the sender should send back everything that was
>>     in the original name identifier from the assertion.  So, for
>>     example, if the IDP fills in all three field<
br>s in the name
>>     identifier in the assertion, the SP should send all three back at
>>     logout time, but if the IDP only fills in two of them, the SP
>>     should only send back those two and omit the third.  But it's
>>     possible that others who don't intend to use the optional fields
>>     might skip parsing and storing them entirely...
>> (2) The schema defines a lib:Assertion element that is not used anywhere.
>>     This is potentially misleading; it is possible that some may assume
>>     that the authentication statement should contain
>>         ...
>>     instead of
>>          ...>...
>>     leading to interoperability problems.  (My understanding is that only
>>     the second is legal inside the AuthenticationStatement.)
>> Has anyone else run in
to these problems?  How have others handled these
>> sections?

Hubert A. Le Van Gong
e-Platform Technology Center
Broadband Services Company
SONY Corporation of America

Jon Serg / serg@Sun.COM

Partial thread listing:

Re: [liberty-dev] 2 items for clarification in protocols and schemas document(continued)
 Hubert A. Le Van Gong (08/12/2002)
 Jonathan Sergent (08/12/2002)
AW: [liberty-dev] Developer Forum Question about SOAP wire protoc ols
(Dittmann Werner)
 John D. Beatty (08/01/2002)
Developer Forum Question about SOAP wire protocols
(Dittmann Werner)


Please enter your comment!
Please enter your name here