[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Repost: Defined Values for the Usage Label
I orginally posted this on December 16, 2002. ---- 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 particular 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 "making 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] | [List Home]