Re: [xacml] FYI: WS-Federation charter includes section on authorizationservices

[Anthony Nadalin <drsecure@us.ibm.com>]

So I'm not sure what you are trying to point out here but these are the concepts anticipated in the WS-Fed charter which do not appear to be addressed by XACML:

1) We want to enable the addition of an authorization context to WS-Trust RSTs to provide additional information for the STS to base its response upon.
2) We want to enable the implementation of an Authorization service using the existing WS-Trust RST/RSTR protocol + the existing security token data structure to return authorization information. The goal is to allow either a client push, or back-end server-server communication path via existing wire protocols to for transmitting authorization data.
3) We want to allow the possibility of expressing authorization decisions as a claims transformation process. This is not focused on the transmission of authorization policy, which seems to be the major focus of XACML.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Prateek Mishra <prateek.mishra@oracle.com>

Prateek Mishra <prateek.mishra@oracle.com>

04/06/2007 08:44 AM

To	XACML TC <xacml@lists.oasis-open.org>
cc
Subject	[xacml] FYI: WS-Federation charter includes section on authorization services

http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/email/archives/200703/msg00002.html

As far as I can determine, XACML isn't referenced anyplace in the charter.


[quote]
Authorization

An authorization service is a special type of Security Token Service
which provides decision brokering services for participants in a
federation. While the internal processing of an authorization service is
implementation specific, interoperability requires development of a
common model for interacting with authorization services, and extensions
to RST/RSTR mechanisms, as defined in WS-Trust [4], for communicating
request and policy inputs and decision outputs.

This work will focus on:

1. Describing how an authorization service may be implemented as a
Security Token Service placed between the requestor and the desired
target service and granting/denying the request by issuing/not issuing
security tokens required by the target service. This includes describing
an abstract mechanism for comparing the claims required by the target
service to the claims proven by the requestor to determine if the
requestor is authorized.

2. Defining the required function of an authorization service to ensure
that the requestor has presented and proven the claims required to
access the target service.

3. Defining the syntax for conveying the authorization context of an RST
or RSTR, as defined in WS-Trust - that is, providing additional
contextual data that may influence token requests but may not be
included in the contents of the issued token. This includes defining
syntax for the following properties: a. Conveying the context item as a
name/value pair. b. Specifying the type of the context item via a URI.
c. Specifying the scope (requestor, target, action) of the context item
via a URI. d. Specifying the value as a simple string or a custom
representation.

4. Defining a dialect for expressing common claims in a format-neutral
way in a manner consistent with the expression of Claim Dialects, as
defined in WS-Trust [4]. This includes defining syntax for the following
properties of a claim: a. Specifying the type of the claim via a URI. b.
Indicating whether the claim is required or optional. c. Specifying the
value of the claim as a string.

5. Defining a profile of WS-Trust [4] in the form of processing rules
for RST/RSTR messages that must be observed by Authorization services
and requestors. This includes a description of the required use and
treatment of: a. Addressing headers as defined in WS-Addressing [9]. b.
Additional authorization context described above. c. The common claim
dialect described above.

[\quote]