Hi Shankar, pls see my comments below.
> > > (1) sts client doesn't need service policy. Algorithm suit as well as > trust assertions have to be obtained from issuer policy. I think there are few bugs related to this issue. Milinda is working on those things. (2) if sts needs entropy from client, who is responsible for creating > it?? is it trust_sts_client or implementation(client/who ever) using > trust_sts_client? IMHO it should be trust_sts_client by looking at the > sts policy. Entropy should be created by client (by setting trust_entropy_t in RST in client code) and also STS should handle it by using populated RSTR (i.e. trust_rstr_get_entropy()) Even server challenge should be handled by trust_sts_client. We currently do not support 'Negotiation and Challenge Extensions' . Yeah sts_client is responsible for handling it. (3) when creating proof token, we can set it as binary secret or > encrypted key. Is there any way to specify which one should be used? There are two procedures for creating proof tokens in current trust implementation. 1 – (Generic way) trust_util_create_requsted_proof_token_element( const axutil_env_t * env, axis2_char_t *wst_ns_uri, axiom_node_t * parent_node, axiom_node_t *req_proof_token) You can create any type of proof token (req_proof_token) and set it to RSTR. 2 – (Most Common procedure) We can create a random session key as the proof token under <wst:BinarySecret> (base64encode value) , and send it to the client. For this case we have to have the assurance that the message is secured. (.i.e encrypted for the Client) For that u can use /*Generating Random Session Key*/ AXIS2_EXTERN axiom_node_t * AXIS2_CALL trust_util_create_random_session_key_proof_token_element( const axutil_env_t * env, axis2_char_t *wst_ns_uri) This is pretty much SAML 1.1 oriented, and you have to have the generated random session key inside the SAML token as well. (sample scenario doen't do this. ) Regards, Kasun
