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

["Reddy, Hari" <Hari.Reddy@CONTENTGUARD.COM>]

Hello Everyone:

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

Regards,

Hari

 

-----Original Message-----
From: Bob Atkinson [mailto:bobatk@Exchange.Microsoft.com]
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: 'rights-requirements@lists.oasis-open.org'
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:

 

1. Staples' Web Service implicitly trusts statements that Staples signs
2. Staples says: Microsoft (that is, key 78910) has the right to initiate the 'purchasing' business process at the Staples web service
3. Staples says: Microsoft is allowed to delegate their right to initiate the 'purchasing' business process at the Staples web service
4. 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.
5. Microsoft says: public key 12345 is paired with a private key owned by a legitimate Microsoft employee
6. Microsoft says: public key 12345 is paired with a private key of an individual named 'Bob Atkinson' (useful in Staples' auditing tools, for example)
7. Microsoft says: public key 12345 is paired with a private key of an individual whose email address is 'bobatk@microsoft.com'. (useful for resolving problems with the order, perhaps)
8. Microsoft says: Passport user bobatk@microsoft.com 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

 

9. 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:

 

1. The ability to assert group membership (E)
2. The ability to issue grants to members of a group (D)
3. The ability to issue grants covering a set of principals (D)
4. The ability to delegate rights that one possesses to other parties (D)
5. The ability to control whether or not the rights one issues are delegable (C)
6. The ability to connect names, email addresses, and various other properties with principals (F,G)
7. 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)
8. 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)
9. 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:

 

10. The ability to carefully control and manage the right to issue other rights.
11. The ability to carefully control and manage the right to delegate rights that one has to others.
12. 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).
13. 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.