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] | [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]