KMLM List

["Boerema, Cate" <Cate.Boerema@xxxxxxxxxxxxxxxxxxxx>]

It is going to be really difficult to develop a SUSHI client that works with 
all providers if they aren't aligned around the standard.  Our SUSHI client is 
currently expecting authentication to be passed through any of the SUSHI 
standard request elements.  If any provider wants to test authenticating that 
way we'd be happy to help them test using our client.

From: Andrew Wiles [aew] [mailto:aew@xxxxxxxxxx]
Sent: Thursday, July 15, 2010 7:16 AM
To: Abdul Habra; Crego,Erin
Cc: Boerema, Cate; sushidevelopers@xxxxxxxxxxxxx
Subject: RE: [sushidevelopers] new sushi deployment for testing

Another method we've seen used for authentication are the WSS extensions to 
SOAP requests. ProQuest and Swetswise use this method.

From: sushidevelopers@xxxxxxxxxxxxx [mailto:sushidevelopers@xxxxxxxxxxxxx] On ;
Behalf Of Abdul Habra
Sent: 15 July 2010 14:42
To: Crego,Erin
Cc: Boerema, Cate; sushidevelopers@xxxxxxxxxxxxx
Subject: Re: [sushidevelopers] new sushi deployment for testing

I found this attached pdf on niso site. 
http://www.niso.org/apps/group_public/download.php/2650/SUSHIauthentication20aug09.pdf

If I understand it correctly, It states that the user name/password could be 
embedded in the RequestorID

Additionally, SOAP allows the envelope to be posted with an http GET (and POST 
of course)
So if the client uses GET, adding username/password as parameters to the URL, 
would it not break the soap request?