Differences between revisions 1 and 2
Revision 1 as of 2008-04-16 08:35:22
Size: 2581
Editor: werner
Comment:
Revision 2 as of 2009-09-20 22:48:21
Size: 2593
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
 1. [#api Consider enhancements to the APIs]
 1.
[#jaxb Support JAX-B generated types from WS-Security schema]
 1. [#dom
Study feasibility of signature/encr without need for DOM (stax?)]
 1.
[#wspolicy Use WS-SecurityPolicy as a configuration API?]
 1.
[#jceprovider Plugable JCE providers]
 1.
[#callback Provide generic callback mechanism to support clients]
 1. [[#api|Consider enhancements to the APIs]]
 1. [
[#jaxb|Support JAX-B generated types from WS-Security schema]]
 1. [[#dom|
Study feasibility of signature/encr without need for DOM (stax?)]]
 1. [
[#wspolicy|Use WS-SecurityPolicy as a configuration API?]]
 1. [
[#jceprovider|Plugable JCE providers]]
 1. [
[#callback|Provide generic callback mechanism to support clients]]
Line 17: Line 17:
[[Anchor(api)]] <<Anchor(api)>>
Line 23: Line 23:
[[Anchor(jaxb)]] <<Anchor(jaxb)>>
Line 29: Line 29:
[[Anchor(dom)]] <<Anchor(dom)>>
Line 35: Line 35:
[[Anchor(wspolicy)]] <<Anchor(wspolicy)>>
Line 41: Line 41:
[[Anchor(jceprovider)]] <<Anchor(jceprovider)>>
Line 47: Line 47:
[[Anchor(callback)]] <<Anchor(callback)>>

Long(er) term goals

n this article we list and discuss new log-term features and enhancements or those features or enhancements that need more discussion, thorough design, or synhcronisation with associated project. The structure of this article is similiar to the WSS4J FAQ: each feature gets a name, an entry in the table of contents, and a detailed description followed by the discussion. Each detailed description and discussion entry shall bear the author's name.

  1. Consider enhancements to the APIs

  2. Support JAX-B generated types from WS-Security schema

  3. Study feasibility of signature/encr without need for DOM (stax?)

  4. Use WS-SecurityPolicy as a configuration API?

  5. Plugable JCE providers

  6. Provide generic callback mechanism to support clients

Consider enhancements to the APIs

Author: Fred (Fred Dushin)

Some description here.

Support JAX-B generated types from WS-Security schema

Author: Fred (Fred Dushin)

Some description here.

Study feasibility of signature/encr without need for DOM (stax?)

Author: Fred (Fred Dushin)

Some description here.

Use WS-SecurityPolicy as a configuration API?

Author: Fred (Fred Dushin)

Some description here.

Plugable JCE providers

Author: ??

Use other JCE providers than BC

Provide generic callback mechanism to support clients

Author: George (George Stanchev), Fred

George: Here is the use case - I have build a WS-Trust client and in some cases I need to be able to refer from the body of the message to security tokens genarated by wss4j (for example X509 certs in signature, username tokens, etc). The particular case I have is the wst:OnBehalfOf element which can either contain the token or have a wss:SecurityTokenReference pointing to the wsu:Id of the token. I think wss4j should provide a way to either use pre-generated pool of wsu:Ids for identifying wss nodes or has a callback may be that allows the client to supply wsu:Id at process time.

Fred: I've been trying to think about a callback mechanism on the processing side, as well. I see we've gotten a few requests for being able to track the data that's been signed or encrypted, and I think using callbacks gives the user a lot more flexibility than by providing data structures, after an event has occurred.

FrontPage/WsFx/wss4jLonger (last edited 2009-09-20 22:48:21 by localhost)