...
The features and tests relate exclusively to the core protocol spec, any other normatively referenced specs, and software components that serve as protocol endpoints. None relate to the Binding Obligations specification because it describes expected behaviors of operators and users of these endpoints, which makes them untestable for the purposes of an interop.
TODO:
- Fill in supporting clauses for resource protection feature(s).
- Discuss and resolve issues under each feature.
F-as-config: AS AS makes available its configuration data in the correct form at the correct location
Supporting clauses | Test ID | Type | Role | Description | Success condition |
---|---|---|---|---|---|
Issues: We no longer say RS and C MUST retrieve the config data. Should we? Should the last two tests here be "opt"? | FT-as-config-data | req | AS | AS provides configuration data that conforms to specified format | Data conforms to format requirements |
FT-as-config-endpts | opt | AS | AS makes config data available through SSL/TLS-protected URL | AS config data endpoint uses https: scheme and RS or client is able to validate AS's certificate | |
FT-rs-get-config-data | req | RS | RS successfully accesses and parses AS config data properties it needs at http://{as_uri}/.well-known/uma-configuration or https://\{as_uri}/.well-known/uma-configuration, including all endpoint-related properties not specific to the client and including handling of non-understood extension properties | RS successfully accesses and parses AS config data | |
FT-c-get-config-data | req | C | Client successfully accesses and parses AS config data properties it needs at http://\{as_uri}/.well-known/uma-configuration or https://{as_uri}/.well-known/uma-configuration, including all endpoint-related properties not specific to the RS and including handling of non-understood extension properties | Client successfully accesses and parses AS config data |
...
Supporting clauses | Test | Type | Role | Description | Success condition |
---|---|---|---|---|---|
Issues: The repetition of the statement in Sec 3.2 should be removed as appropriate. | FT-rs-get-pat | req | AS | AS issues PAT to RS given correct OAuth authorization_code grant flow (required by the spec) and request for protection API | AS issues PAT to RS IFF RS engages correctly and with correct scope |
FT-as-pat-profile | opt | AS | AS supports additional PAT token types as declared in configuration data | ? | |
FT-as-pat-grant-types | opt | AS | AS supports additional PAT grant types as declared in configuration data | ? | |
FT-as-require-pat | req | AS | AS requires OAuth clients of protection API (definitionally, RSs) to present valid OAuth access tokens with protection API scope in order to use endpoints | AS allows RSs to make protection API calls IFF they present protection API scope | |
FT-rs-use-pat | req | RS | RS presents valid OAuth access token with protection API scope when making calls to all protection API endpoints | RS presents PAT to all protection API endpoints |
...
Supporting clauses | Test | Type | Role | Description | Success condition |
---|---|---|---|---|---|
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. | 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-profile | opt | AS | AS supports additional AAT token types as declared in configuration data | ? | |
FT-as-aat-grant-types | opt | AS | AS supports additional AAT grant types as declared in configuration data | ? | |
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-require-aat | req | AS | AS requires OAuth clients of authorization API to present valid OAuth access tokens with authorization API scope in order to use endpoints | AS allows client to make authorization API calls IFF they present authorization API scope |
...
Supporting clauses | Test | Type | Role | Description | Success condition |
---|---|---|---|---|---|
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? | 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. | RS uses all elements of resource set registration API and scope description format 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 |
F-protect-rsrc: RS, AS, and client interact to enable authorized access to protected resources and block unauthorized access
Supporting clauses | Test ID | Type | Role | Description | Success condition |
---|---|---|---|---|---|
Supporting clauses | Test ID | Type | Role | Description | Success condition |
| a scope description contains extension properties, the AS proceeds normally in handling the scope descriptionAS does not produce an error on encountering extension properties in scope description |
F-protect-rsrc: RS, AS, and client interact to enable authorized access to protected resources and block unauthorized access
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.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? Add OpenID Connect claim profile-specific tests to support interop scenarios? | FT-unprotected-resource | req | RS | RS responds to access request for unprotected resource without including anything UMA-specific in the response | RS responds in non-UMA fashion |
FT-no-rpt | req | RS | RS responds to client not bearing an RPT with HTTP 401 and correct as_uri corresponding to resource to which access was attempted | RS responds with HTTP 401 and as_uri | |
FT-c-get-rpt | req | C | Client presents valid AAT at AS's RPT endpoint to get RPT; if an existing RPT associated with this AAT was still valid, it is invalidated when the new RPT is issued | Client qualifies for and gets new or refreshed RPT | |
FT-as-issue-rpt | req | AS | AS issues RPT in response to client's request for an RPT at the correct endpoint with a valid AAT | AS issues RPT | |
FT-rs-introspect-rpt | req | RS | RS presents valid RPT at AS's token introspection endpoint to get token's status | RS gets well-formed RPT status | |
FT-as-introspect-rpt | req | AS | AS returns RPT's status in response to RS request | AS returns well-formed RPT status | |
FT-rs-invalid-rpt | req | RS | RS responds to client bearing invalid RPT with HTTP 401 and correct as_uri corresponding to resource to which access was attempted | RS responds with HTTP 401 and as_uri | |
FT-rs-register-permission | req | RS | RS presents valid PAT at AS's permission registration endpoint to register a requested permission that would suit for the type of access attempted | RS registers requested permission | |
FT-as-permission-ticket | req | AS | AS registers permission associated with correct resource owner and resource set and returns securely random permission ticket in response to RS registration of requested permission | AS returns permission ticket that is securely random | |
FT-rs-insufficient-perms | req, rptbearer | RS | RS responds to client bearing valid bearer RPT with insufficient permissions with HTTP 403, as_uri, and permission ticket corresponding to resource for which access was attempted | RS responds with HTTP 403, as_uri, and permission ticket | |
FT-c-add-authz-data | req | C | Client presents valid AAT, valid RPT, and permission ticket at AS's authorization endpoint to POST request that authorization data be associated with RPT | Client receives back normal success or error message | |
FT-as-deny-authz-data | req | AS | AS determines that the client should not get authorization data, and returns either an invalid_ticket error, an expired_ticket error, or a not_authorized_permission error | AS returns one of the errors | |
FT-as-give-authz-data | req | AS | AS associates new authorization data with the RPT that the client presented and responds with success, based on "user policies" ? | AS adds authorization data and responds with success | |
FT-as-need-claims | req, rptbearer | AS | AS indicates it needs requesting party claims to considering adding permission to "bearer" RPT | AS responds to the client with a need_claims error | |
FT-c-claims-redirect | req | C | Client redirects requesting party to AS to provide claims, providing a redirect URI, a callback URI, and a state parameter | AS redirects requesting party to AS | |
FT-rs-respect-authz-data | req | RS | RS limits access to resource that is currently under protection at an AS for which a valid RPT with valid authorization data has not been presented by a client | RS blocks and grants client's access according to RPT's current status |