[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] FW: [rights-requirements] FW: web servicesrequirements for Right s Language
This message was posted to the RLTC requirements list. I presume something similiar will be proposed to the WSSTC when it is formed.
It may be a useful exercise to consider to what extent SAML or SAML+XACML or SAML+XACML+something else can address these requirements.
Obviously, it is also possible to question certain aspects of the requirements themselves. For example, I would assume point #12 under "richer scenarios" is controversial.
From: Bob Atkinson
Sent: Wednesday, August 07, 2002 10:26 AM
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:
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
Though simple, this scenario is very typical and illustrates several requirements, among them the following:
Slightly richer scenarios bring to the fore some other requirements:
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.
Powered by eList eXpress LLC