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

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