chung wrote on 06/16/2010 07:13 PM:
> Hi Andreas, All,
>   I think it is inevitable to avoid having the parameter 'subjectid' in
> the Header of the request since the posted data have content-type
> application/xml and not application/x-www-form-urlencoded. So I think it
> is OK using the header in that case. I've built some Java classes which
> are available at

You mean when uploading a policy? It is already in the header, is it?

> http://github.com/alphaville/yaqp-turbo/tree/xtreme/src/org/opentox/www/aa/
> Using the PolicyManager you can create a policy on the remote server.
> However I still use HTTP. Has anybody tried to build a client based on
> SSL? I'd also like to repeat here the question of Luchesar about if we
> are going to have some Certificate for secure data transactions?

As a related information: Christoph has installed a certificate that is 
by default trusted by most user agents (including major browsers) at 
opensso.in.silico.ch this afternoon.

> I also have a question about user attributes. Now, user information (as
> returned by the openSso server) are available in the following text
> format:
>
> userdetails.token.id=<TOKENID>
> userdetails.attribute.name=uid
> userdetails.attribute.value=YAQPservice
> userdetails.attribute.name=mail
> userdetails.attribute.value=<EMAIL>
> userdetails.attribute.name=userpassword
> userdetails.attribute.value={SSHA}<PASSWORD>
> userdetails.attribute.name=sn
> userdetails.attribute.value=unset
> userdetails.attribute.name=cn
> userdetails.attribute.value=<CN>
> userdetails.attribute.name=dn
> userdetails.attribute.value=<DN>
> userdetails.attribute.name=objectclass
> userdetails.attribute.value=organizationalPerson
> userdetails.attribute.value=person
> userdetails.attribute.value=inetOrgPerson
>
>
> Is it possible to provide these information in XML too?

In principle yes, the above is the original output by ssoadm, the server 
management tool.

Regards
Andreas