- From: Anthony Nadalin <drsecure@us.ibm.com>
- Date: Wed, 4 Oct 2006 08:44:07 -0500
- To: "Sverdlov, Yakov" <Yakov.Sverdlov@ca.com>
- Cc: public-ws-policy@w3.org, public-ws-policy-request@w3.org
- Message-ID: <OF68C2E448.38B57578-ON862571FD.004B4CAA-862571FD.004B7378@us.ibm.com>
So I have a better idea (or at least a different idea), we (the WSSX TC) have now a draft of a scenarios document that describes our interop scenarios and this is now annotated with WS-SecurityPolicy assertions, I suggest that we take those scenarios. Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 "Sverdlov, Yakov" <Yakov.Sverdlov@c a.com> To Sent by: <public-ws-policy@w3.org> public-ws-policy- cc request@w3.org Subject New Issue 3793: Add example about 10/04/2006 08:27 policies in the context of AM relationships between multiple entities I wanted to send this proposal before the today’s optionality tar ball so as to provide additional context. The purpose of the proposal is to add an example in the Primer (probably in the section 2.5 Combining Policy Assertions or 3.3 Policy Data Model) about dealing with requirements and capabilities of entities as [optional] behaviors in the most basic use case for requester and provider. I am suggesting the outline of the use case. I can come up with the actual text if the WG will agree with the approach. The example may describe policy design for the WS-Security token authentication scheme when only two entities – requester and provider – are involved. The following four policy assertions with respect to the corresponding entities may be considered: 1. “The provider only accepts WS-Security tokens as means of the authentication” 2. “The provider may accept WS-Security tokens as means of the authentication” (optional="true") 3. “The requester must attach the WS-Security token to a message” 4. “The requester may attach the WS-Security token to a message” (optional="true") I think that briefly describing some combinations of one or more assertions above will provide policy designers with a good understanding of policy assertion choices and possible policy enforcement implications. The example would also show that typically any policy assertion should deal with one entity at a time, and that combinations of assertions (behaviors) would allow the designers to cover relationships/dependencies between entities. Regards, Yakov Sverdlov CA
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic24195.gif
- image/gif attachment: ecblank.gif
Received on Wednesday, 4 October 2006 13:49:52 UTC