[rights-requirements] FW: web services requirements for Rights Language

Hello 
Everyone:

The 
OASIS list serv has been having problems lately...

Regards,

Hari

 

-----Original Message-----
From: Bob Atkinson 
[mailto:]
Sent: Wednesday, August 07, 
2002 1:45 PM
To: Reddy, Hari
Subject: FW: web services 
requirements for Rights Language

I tried to send this directly to the 
list, but it bounced back saying that I was not authorized. 'Don't know what's 
up, but could you please post this? Thanks.

 

                
Bob

 

-----Original 
Message-----
From: Bob Atkinson 

Sent: Wednesday, 
August 07, 2002 10:26 
AM
To: 
''
Subject: web services requirements for 
Rights Language

 

The requirements for a rights 
language (a.k.a. an authorization policy language) arising from the Web Services 
community has (perhaps not very surprisingly) much overlap with many other 
domains for which an authorization policy language is required. However, the 
domain does drive some perhaps somewhat unique requirements.

 

The most important usage pattern of 
an authorization policy language in this domain is as the means by which the 
credentials that convey the authority to carry out a particular web services 
request are conveyed: a SOAP request message arrives at a server, requesting 
that it carry out a certain operation. Associated with the request (likely 
contained within the headers thereof, but not necessarily) are a set of 
credentials (possibly of various formats) that are used by the server in 
determining whether it will carry out the operation requested. The REL ought to 
be well-suited for this sort of application.

 

 

By way of a (hypothetical) concrete 
illustrative example, suppose Microsoft has a relationship with Staples wherein 
Microsoft is allowed to purchase office supplies from Staples at advantageous 
prices. This is a company-to-company contractual relationship, the setting up of 
which involved both many lawyers and possibly also some exchange of technical 
artifacts, such as the public keys that are paired with the private keys by 
which Microsoft and Staples will sign their respective digital correspondence 
related to this contract.

 

Once the contract is in place, if 
Staples were to receive an electronic Purchase Order (P.O.) signed under the key 
provided by Microsoft as part of the contract, it would, presumably consider 
that authorized and proceed to fulfill the order.

 

But suppose, as is reasonably the 
case, that the intent is to instead allow Microsoft employees to make orders 
directly to Staples. Were I to make such an order, a P.O. shows up on Staples' 
doorstep signed under a key pair associated with Bob Atkinson, a key that 
Staples has never heard of before. What could I reasonably also convey in that 
P.O that would convince them to ship the order?

 

Clearly, I must convey some sort of 
authorization from Microsoft that I am a legitimate employee and am permitted to 
participate in the relationship. Concretely, the overall set of authorization 
policies that Staples computes against could look something like the 
following:

 

  
Staples' Web Service implicitly 
  trusts statements that Staples signs 
  
Staples says: Microsoft (that is, 
  key 78910) has the right to initiate the 'purchasing' business process at the 
  Staples web service 
  
Staples says: Microsoft is allowed 
  to delegate their right to initiate the 'purchasing' business process at the 
  Staples web service 
  
Microsoft says: any Microsoft 
  employee can initiate the 'purchasing' business process at the Staples web 
  service, but only up to a total P.O. amount of $1000. 
  
Microsoft says: public key 12345 
  is paired with a private key owned by a legitimate Microsoft 
  employee 
  
Microsoft says: public key 12345 
  is paired with a private key of an individual named 'Bob Atkinson' (useful in 
  Staples' auditing tools, for example) 
  
Microsoft says: public key 12345 
  is paired with a private key of an individual whose email address is 
  ''. (useful for resolving problems with the order, 
  perhaps) 
  
Microsoft says: Passport user 
   is a legitimate Microsoft employee (presumably here 
  correspondence is ultimately carried out on a secure channel over which 
  Passport authentication has been done rather than using signed 
  messages) 

 

Here, 'Microsoft says:' 
(respectively, 'Staples says:') is intended to denote a statement signed under 
the key pair made known to Staples (respectively, Microsoft) in the 
context-establishing contract. All of these statements would presumably be 
decorated with 

 

  
Expiration dates, revocation 
  availability information, and other typical administrative gunk. 
  

 

 

Though simple, this scenario is very 
typical and illustrates several requirements, among them the 
following:

 

  
The ability to assert group 
  membership (E) 
  
The ability to issue grants to 
  members of a group (D) 
  
The ability to issue grants 
  covering a set of principals (D) 
  
The ability to delegate rights 
  that one possesses to other parties (D) 
  
The ability to control whether or 
  not the rights one issues are delegable (C) 
  
The ability to connect names, 
  email addresses, and various other properties with principals 
  (F,G) 
  
The ability to invent 
  application-specific conditions, perhaps necessitating application-specific 
  context (here, the contextual P.O transmitted in the message) and have that 
  context appropriately integrated into the authorization algorithm 
  (D) 
  
The ability to invent new kinds of 
  principals (presumably associated with new kinds of authentication mechanisms) 
  and have those kinds of principals be first-class-participants within the 
  authorization framework (H) 
  
The ability to appropriately 
  control and administer in a reasonable risk-balanced manner the authorization 
  policies that one has disseminated (I) 

 

Slightly richer scenarios bring to 
the fore some other requirements:

 

  
The ability to carefully control 
  and manage the right to issue other rights. 
  
The ability to carefully control 
  and manage the right to delegate rights that one has to others. 
  
The ability to express all the 
  authorization policies that can be semantically conveyed using the X509.v3 
  infrastructure (that is, the authorization policy language ought to be able to 
  fully subsume the semantics of X509.v3). 
  
The ability to express all the 
  authorization policies that can be semantically conveyed within a Kerberos 
  ticket (more correctly, the Privilege Access Certificate (PAC)) 
  

 

An authorization policy 
infrastructure that met the above set of requirements would go a long way to 
being very broadly useful within the Web Service community.