Hi Michel where goes my 2 cents for you to accomplish that:
1. Create a method called login in your web service that method receives the user name plus the password and returns a cookie that can them be use by subsequent call's.
2 Now each of your web service methods receives a parameter called cookie.

with this approach you can even keep user preferences, this is the way I design all of my web services.
I'm considering in writing an article to show this in the Universal Thread magazine what d you think?

>>>But, that's an interesting subject about the properties. It's true at first I thought we would be able to do that also. Do you think at long term, that could be possible?
>>
>>Very good question. Browers have managed to do it, but it seems like there's always a security and privacy risk there. Also, we would be adding alot of complexity to the Simple Object Access Protocol, both on the client and the server, were the use of Web Services should be so simple and portable that we can use SOAP from any device (the old laptop, cell phone, refridgarotr bit). I also think that scalability would suffer as well.
>>
>>Its really a question of, do we NEED stateful objects? I can't say, but I doubt it. If you think so, what can we do with statful objects that we can't do with stateless ones?
>>
>>>I mean if a Web Service would support a connection state, then it could open the door to various new possibilities.
>>
>>Like what?
>
>Well, this would bring a totally new dimension. For example, keeping a connection state would allow us to offer something like UT is offering from the Web but locally. Thus, instead of passing username and password for each method, we'll pass them once and them keep the connection opened for all other calls. Kinda like the session object of ASP.