...
Core 1: "The (authorization) API is OAuth-protected and requires an authorization API token (AAT) for access." (non-normative)
- Core 1.3.1: "The authorization server presents a protection API to the resource server and an authorization API to the client. These APIs MUST be OAuth-protected; thus, the authorization server has an OAuth token endpoint and user authorization endpoint, and has the option to issue an OAuth refresh token along with any access tokens issued for these APIs."
- Core 1.3.1: "An entity seeking authorization API access MUST request the scope "http://docs.kantarainitiative.org/uma/scopes/authz.json", and an access token with at least this scope is called an authorization API token (AAT). The same entity can serve in both roles, so that an OAuth access token might be considered both a PAT and an AAT if it has both scopes. If a request to an endpoint fails due to an invalid, missing, or expired PAT or AAT, or requires higher privileges at this endpoint than provided by the PAT or AAT, the authorization server responds with an OAuth error."
- Core 1.3.1: "The authorization server is REQUIRED to support the OAuth bearer token profile for PAT and AAT issuance, and MAY support other OAuth token profiles for these purposes. It MUST declare all supported token profiles for PAT and AAT issuance in its configuration data."
- Core 1.3.1: "The authorization server MAY support the use of any OAuth grant type for PAT and AAT issuance, but MUST support the authorization_code grant type, and SHOULD support the SAML bearer token grant type [OAuth-SAML] (urn:ietf:params:oauth:grant-type:saml2-bearer) if it anticipates working with entities that are operating in environments where the use of SAML is prevalent. It MUST declare its supported grant types for PAT and AAT issuance in its configuration data."
- Core 1.4: "aat_profiles_supported - REQUIRED."
- Core 1.4: "aat_grant_types_supported - REQUIRED."
- Core 1.4 : "token_endpoint - REQUIRED."
- Core 1.4 : "user_endpoint - REQUIRED."
- Core 1.4 : "A valid PAT MUST accompany requests to this (rpt_endpoint) protected endpoint."
- Core 1.4 : "A valid PAT MUST accompany requests to this (authorization_request_endpoint) protected endpoint."
- Core 3: "If the client does not already have an AAT at the appropriate authorization server to be able to use its authorization API, it first obtains one." (non-normative)
- Core 3.4: "2. The client acquires an AAT. This enables it to use authorization API endpoints." (non-normative)
- Core 3.4.1: "It (client) obtains an RPT by performing a POST on the RPT endpoint. It MUST provide its own valid AAT in the header."
- Core 3.4.2: "It (client) performs a POST on the authorization request endpoint, supplying its own AAT in the header and its RPT and the permission ticket in a JSON object with properties "rpt" and ticket", respectively."
Issues
- How should the optional test success conditions be worded? Should we even test this? Does anyone want to do those yet? Perhaps they should be associated with only profile-specific features that are defined by the relevant stakeholders. (See also F-pat.)
| Test | Type | Role | Description | Success | |||||
|---|---|---|---|---|---|---|---|---|---|
| FT-c-get-aat | req | AS | AS issues AAT to Client given correct OAuth authorization_code grant flow (required by the spec) and request for authorization | AS issues AAT to client IFF client engages correctly and with correct scope | |||||
| FT-as-aat-saml | opt | AS | AS issues AAT to Client given correct OAuth SAML (urn:ietf:params:oauth:grant-type:saml2-bearer) bearer token grant type and request for authorization | AS issues AAT to client IFF client engages correctly and with correct scope | |||||
| FT-as-aat-config | req | AS | AS supports AAT grant types as declared in configuration data | AS configuration data contains at least authorization_code grant type and optionally SAML bearer token grant type for AATs | |||||
| FT-as-rsrrequire-scopesaat | req | AS | AS retrieves (or attempts to retrieve) scope descriptions associated with resource set description at the time RS registers and updates it, and also attempts to re-retrieve relevant scope descriptions whose cached versions have expired when resource owner begins an AS interaction session | AS attempts to retrieve scope descriptions | FT-as-require-aat | req | AS | AS requires OAuth clients of authorization API to present valid requires OAuth clients of authorization API (definitionally, Clients) to present valid OAuth access tokens with authorization API scope in order to use endpoints | AS allows client Client to make authorization API calls IFF they present authorization API scope |
| FT-c-use-aat | req | C | Client presents valid OAuth access token with authorization API scope when making calls to all authorization API endpoints | Client presents AAT to all authorization API endpoints |
F-rsr: RS registers resource sets at AS in order to put them under AS protection
...
- Core 2: "In an ongoing fashion, the resource server registers any resource sets with the authorization server for which it intends to outsource protection, using the process defined by [OAuth-resource-reg]." (non-normative)
- RSR 2.1: "Scope descriptions MAY contain extension properties that are not defined in this specification."
- RSR 2.2: "When a resource server creates or updates a resource set description (see Section 2.3), the authorization server MUST attempt to retrieve the referenced scope descriptions so that it can present fresh data in any resource owner interactions."
- RSR 2.3: "Following is a summary of the five registration operations the authorization server is REQUIRED to support. Each is defined in its own section below. All other methods are unsupported." (see all RSR 2.3 subsections)
- RSR 2.3: "If the request to the resource set registration endpoint is incorrect, then the authorization server responds with an error message by including one of the following error codes with the response..."
Issues
- RSR 2.1: s/scope/Scope/ at beginning of sentence.
- Need some special error condition if a scope description is malformed?
- We no longer say anything explicit about cached versions of resource set descriptions; should we? If not, revise RT-as-rsr-scopes?
| Test | Type | Role | Description | Success |
|---|---|---|---|---|
| Test | Type | Role | Description | Success |
| FT-as-rsr | req | AS | AS successfully presents all of the following methods at a resource set registration endpoint of form {rsreguri}/resource_set/{rsid}, and treats others as unsupported: PUT with unique ID to register new resource set description; GET with unique ID to read already-registered resource set description, handling the presence of any policy_uri property in AS's response; PUT with If-Match and unique ID to update already-registered resource set description, handling the presence of any policy_uri property in AS's response; DELETE with a unique ID to delete an already-registered resource set description; and GET on resource_set path to read list of already-registered resource set descriptions. | AS presents all elements of resource set registration API correctly |
| FT-rs-rsr | req | RS | RS successfully uses: PUT with unique ID to register new resource set description; GET with unique ID to read already-registered resource set description, handling the presence of any policy_uri property in AS's response; PUT with If-Match and unique ID to update already-registered resource set description, handling the presence of any policy_uri property in AS's response; DELETE with a unique ID to delete an already-registered resource set description; and GET on resource_set path to read list of already-registered resource set descriptions. RS links to well-formed scope descriptions and provides well-formed resource set descriptions. | RS uses all elements of resource set registration API and scope and resource set description format formats correctly |
| FT-as-rsr-error | req | AS | AS issues errors for error conditions, including unsupported_method_type, not_found, and precondition_failed. | AS issues resource set registration API errors for error conditions |
| FT-as-rsr-scopes | req | AS | AS retrieves (or attempts to retrieve) scope descriptions associated with resource set description at the time RS registers and updates it, and also attempts to re-retrieve relevant scope descriptions whose cached versions have expired when resource owner begins an AS interaction session | AS attempts to retrieve scope descriptions |
| FT-as-rsr-scope-display | opt | AS | In the interface it presents to a resource owner, AS uses scope names and any icons defined as part of registered scope descriptions associated with that resource owner | AS displays scope description information |
| FT-as-rsr-scope-ext | req | AS | If a scope description contains extension properties, the AS proceeds normally in handling the scope description | AS does not produce an error on encountering extension properties in scope description |
...
- Core 1.3.2: "The resource server presents one or more protected resource endpoints to the client; these endpoints are protected by the UMA profile of OAuth and require a requesting party token (RPT) with sufficient authorization data for access." (non-normative)
- Core 1.3.2: "This specification defines one RPT profile, call "bearer" (see Section 3.3.2), which is REQUIRED for the authorization server to support."
- Core 2: "Once a resource set has been placed under authorization server protection through the registration of a resource set description for it, and until such a description's deletion by the resource server, the resource server MUST limit access to corresponding resources, respecting authorization data associated with client-presented RPTs by the authorization server as appropriate."
- Core 3: "Each interaction (as part of getting authorization and access a resource) MAY be the last, if the client chooses not to continue pursuing the access attempt or the resource server chooses not to continue facilitating it."
- Core 3.1.1: "If the client does not present an RPT with the request, the resource server MUST return an HTTP 401 (Unauthorized) status code, along with providing the authorization server's URI in an "as_uri" property to facilitate authorization server configuration data discovery, including discovery of the endpoint where the client can request an RPT."
- Core 3.1.2: "If the client presents an RPT with its request, the resource server MUST determine the RPT's status (see Section 3.3) before responding. If the RPT is invalid, the resource server MUST return an HTTP 401 (Unauthorized) status code, along with providing the authorization server's URI in an "as_uri" property in the header, similarly to the case where no RPT was presented."
- Core 3.1.2: "If the RPT is valid but has insufficient authorization data for the type of access sought, the resource server SHOULD register a requested permission with the authorization server that would suffice for that scope of access (see Section 3.2), and then respond with the HTTP 403 (Forbidden) status code, along with providing the authorization server's URI in an "as_uri" property in the header, and the permission ticket it just received from the AM in the body in a JSON-encoded "ticket" property."
- Core 3.1.2: "If the RPT's status is associated with authorization data that is consistent with authorized access of the scope sought by the client, the resource server MUST give access to the desired resource."
- Core 3.1.2: "The resource server MUST NOT give access where the token's status is not associated with sufficient authorization data for the attempted scope of access."
- Core 3.2: "The (permission) ticket value MUST be securely random (for example, not merely part of a predictable sequential series), to avoid denial-of-service attacks."
- Core 3.2: "If the registration request is successful, the authorization server responds with an HTTP 201 (Created) status code and includes the Location header in its response as well as the "ticket" property in the JSON-formatted body."
- Core 3.2: "If the registration request is authenticated properly but fails due to other reasons, the authorization server responds with an HTTP 400 (Bad Request) status code and includes one of the following UMA error codes..."
- Core 3.3.2: "On receiving an RPT of the "Bearer" type in an authorization header from a client making an access attempt, the resource server MUST introspect the token by using the authorization server's token introspection endpoint. ... The authorization server responds with a JSON object with the structure dictated by [OAuth-introspection]."
- Core 3.4.1: "It (client) obtains an RPT by performing a POST on the RPT endpoint. ... The authorization server responds with an HTTP 201 (Created) status code and provides a new RPT."
- Core 3.4.1: "If the AAT provided in the header is the same as one provided for a previously issued still-valid RPT by this authorization server, the authorization server invalidates the old RPT and issues a new one."
- Core 3.4.2: "It (client) performs a POST on the authorization request endpoint, supplying its own AAT in the header and its RPT and the permission ticket in a JSON object with properties "rpt" and ticket", respectively."
- Core 3.4.2: "The authorization server MUST base the addition of authorization data to RPTs on user policies."
Issues
- Break down these feature tests into smaller chunks? What makes sense? The list of supporting clauses will be huge once we fill it in. Some candidates: MTI "bearer" RPT support vs. other profiles.
- "User policies" isn't testable; how do we shore up this wording in FT-as-give-authz-data?
- Need more rptbearer-specific tests?
- Add claimoidc-specific tests?
...