Hi Werner; Thanks very much for the comment!
> However, the policy files are not designed (and it is also > not their purpose) to hold every information necessary > to actually generate and run the client. I agree, But I think now it is time to identify them and derive them from the users environment if possible. I group information need to run a client as following 1) information derive from the WS-Policy 2) information that are part security module (global scope), e.g. User usually use one key store for everything, and usually have a one identity e.g. Globus credentials 3) Other information, mostly provided as parameters in the MessageContext/Operations ect I think best way to go is to try to retrive the information from the message context, this will look up the information hierarchy and information on the top will take precedence. When the information is missing we can assume default values. > IMHO we need additional deployment descriptors to complement > the information contained in the policies. For example, a > policy may define that a token is required (e.g. X.509) but > the policy does not define which token (i.e. who is the owner > of the token). We can define and try to use extensions to the policy. On the other hand we can have a default case. When policy says X.509, then token type do not matter, and server is saying he is handling any X.509 token. (I think WSS4J handle most of them, and I Guss it is good way to go on). We can let user set the default case on the module level. > Also the WS Policy specifications are in flux and IMHO > need some "brush-up" to be really usable. this auto configuring client thingy is a big part of Web Service Dream :) Let us go ahead making assumptions on the way. We can refine them once we have something working! AFAIK, you and ruicth are the (only) people who try to use policy in real life, Please give us feedback on the way! Srinath ============================ Srinath Perera: http://www.cs.indiana.edu/~hperera/ http://www.bloglines.com/blog/hemapani
