...
NOTE: This page is very much in - progress. The full draft set of features and feature tests is attached.
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 document because this document describes expected behaviors of operators and users of these endpoints, which makes them untestable for the purposes of an interop.
Feature ID | Type | Description | Test ID | Type | Role | Description | Succeed | FailSuccess condition | ||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
F-as-config | req | AS makes available its configuration data in the correct form at the correct location. Supporting clauses:
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 requirementsFails | |||||||
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 | Fails | |||||||||
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 dataFails | ||||||||||
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 | Fails | |||||||||
F-dyn-client-reg | opt | AS supports generating dynamic client credentials and RS and client support getting them. Supporting clauses:
Issues: Typo in Core Sec 1.4: s/absent/absence/ | FT-as-dyn-client-reg | opt | AS | AS config data "dynamic_client_endpoint" property is non-null | AS config data "dynamic_client_endpoint" property has a valid URL value for a DynClientReg endpoint | Fails | ||||||
FTFT-rs-get-dyn-client-creds | opt | RS | RS interacts with AS to request and receive client credentials dynamically | RS gets client credentials dynamicallyFails | ||||||||||
FT-c-get-dyn-client-creds | opt | C | C interacts with AS to request and receive client credentials dynamically | C gets client credentials dynamicallyFails | ||||||||||
F-pat | req | AS successfully issues PAT to RS for use at AS's protection API. Supporting clauses:
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 | Fails | ||||||
FT-as-pat-profile | opt | AS | AS supports additional PAT token types as declared in configuration data | ?Fails | ||||||||||
FT-as-pat-grant-types | opt | AS | AS supports additional PAT grant types as declared in configuration data | ? | Fails | |||||||||
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 scopeFails | ||||||||||
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 endpointsFails | ||||||||||
F-aat | req | AS successfully issues AAT to Client for use at AS's authorization API. Supporting clauses:
| 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 scopeFails | |||||||
FT-as-aat-profile | opt | AS | AS supports additional AAT token types as declared in configuration data | ?Fails | ||||||||||
FT-as-aat-grant-types | opt | AS | AS supports additional AAT grant types as declared in configuration data | ?Fails | ||||||||||
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 | Fails | |||||||||
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 | Fails | |||||||||
F-rset-reg | req | RS registers resource sets at AS in order to put them under AS protection. Supporting clauses:
Issues: RSR 2.1: s/scope/Scope/ at beginning of sentence. Need some special error condition if a scope description is malformed? | FT-as-rset-reg | 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-rset-reg | 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-rset-reg-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-rset-reg-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-rset-reg-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-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 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." | ||||||||||||||
...