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

[Hal Lockhart <hal.lockhart@entegrity.com>]

Phil,

 

I hope you din't mind me replying on the list. I think agreeing on terminology is an important aspect of this. (and anyway your comment is the only one I have received)

 

The problem is that we have terminology from two distinct domains, which refers to different concepts.

 

The SOAP messaging model consists of a one way flow from an Initial Sender to a Ultimate Receiver, which may pass through one or more Intermediaries. When focusing on a single hop we can simply refer to a Sender and a Receiver, to indicate that we don't care whether either one is an end point.

 

From this basic flow, we can build up more complex Message Exchange Patterns (MEP) such as request/response, publish/subscribe, mulicast, reliable messaging and so forth. Authorization Policy operates at this higher MEP level.

 

I think the Requester will usually be an Initial Sender, but the converse is not true. (e.g. the return flow in Req/Resp)

 

The SOAP Intermediaries will generally be Authorization Intermediaries, but I can imagine flows in which an Initial Sender or an Ultimate Receiver might be as well. The Recipient (when distinct from the Requester) and the Codebase will usually not be part of the SOAP flow at all. I am also not sure how a reqesting machine would be represented in a SOAP environment, so I left it off.

 

That said, I could live with calling the Requester, the Initiator instead.

 

Hal

-----Original Message-----
From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com]
Sent: Monday, December 16, 2002 7:02 PM
To: Hal Lockhart
Subject: Re: [wss] WSS Defined Values for the Usage Label

Hal,

Is Requester the same as Sender? I tend to write in XCBF of
message Sender's and Recipient. This is a holdover from CMS
thinking.

Phil


Hal Lockhart wrote:

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