OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [wss] WSS Defined Values for the Usage Label


Title: WSS Defined Values for the Usage Label

At the F2F I agreed to lead an effort to define a set of standard values and their semantics for use in the Usage Label. I welcome everyone's comments and suggestions.

In my original proposal on this subject I suggested values be defined for:

Requester
Recipient
Intermediary
Codebase

My motive is to provide the data that can be used by an XACML policy. These values are defined in XACML along with one other:

machine

The XACML definitions and the associated identifiers (stripped of their URN prefix are:

------
access-subject - This identifier indicates the system entity that initiated requesting access.  That is, the first entity in a request chain.  If subject category is not specified, this is the default value.

recipient-subject - This identifier indicates the system entity that will receive the results of the request.  Used when it is distinct from the access-subject.

intermediary-subject - This identifier indicates a system entity through which the access request was passed. There may be more than one.  No means is provided to specify the order in which they passed the message.

codebase - This identifier indicates a system entity associated with a local or remote codebase that generated the request.  Corresponding subject attributes might include the URL from which it was loaded and/or the identity of the code-signer.  There may be more than one.  No means is provided to specify the order they processed the request.

requesting-machine - This identifier indicates a system entity associated with the computer that initiated the access request.  An example would be an IPsec identity.

-----

To be honest, I am not enamored of these partucular names (access-subject in particular) however these are roughly the semantics I have in mind. The main change I would suggest is that in a SOAP, single message context, the definitions should not just say "makeing a request" but also include "orginating the content" to cover the case of responses of unsolicited data.

Hal



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC