[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]