OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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













[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]