...
Tests could be added to cover additional UMA WG-specified or third-party profiles, in which case the possible type values will expand. Generic high-level features of the protocol have an ID in the form "F-", and they group feature tests that have an ID in the form "FT-".
...
1. F-as-config: AS makes available its configuration data in the correct form at the correct location
The feature tests in this section have been reviewed.
...
| Test ID | Type | Role | Description | Success |
|---|---|---|---|---|
| FT-as-config-data | req | AS | AS provides configuration data that conforms to specified format | Data conforms to format requirements |
| FT-as-config-endpts | req | AS | AS makes config data available through https://\{as_uri}/.well-known/uma-configuration | AS config data endpoint uses https: scheme with specific URL form, with a valid certificate |
| FT-rs-get-config-data | opt | RS | RS successfully accesses and parses AS config data properties it needs at 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 | RS successfully accesses and parses AS config data |
| FT-c-get-config-data | opt | 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 client and including handling of non-understood extension properties | Client successfully accesses and parses AS config data |
2. F-dyn-client-reg: AS supports generating dynamic client credentials and RS and client support getting them
The feature tests in this section have been reviewed.
...
| Test ID | Type | Role | Description | Success |
|---|---|---|---|---|
| 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 |
| FT-rs-get-dyn-client-creds | opt | RS | RS interacts with AS to request and receive client credentials dynamically | RS gets client credentials dynamically |
| FT-c-get-dyn-client-creds | opt | C | C interacts with AS to request and receive client credentials dynamically | C gets client credentials dynamically |
3. F-pat: AS successfully issues PAT to RS for use at AS's protection API
The feature tests in this section have been reviewed.
...
| Test | Type | Role | Description | Success |
|---|---|---|---|---|
| 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-saml | opt | AS | AS issues PAT to RS given correct OAuth SAML (urn:ietf:params:oauth:grant-type:saml2-bearer) bearer token grant type and request for protection API | AS issues PAT to RS IFF RS engages correctly and with correct scope |
| FT-as-pat-config | req | AS | AS supports PAT 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 PATs |
| 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 |
4. F-aat: AS successfully issues AAT to Client for use at AS's authorization API
The feature tests in this section have been reviewed.
...
| 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-require-aat | req | AS | AS 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 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 |
5. F-rsr: RS registers resource sets at AS in order to put them under AS protection
The feature tests in this section have been reviewed.
...
| 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 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-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 |
6. F-protect-rsrc: RS, AS, and client interact to enable authorized access to protected resources and block unauthorized access
The feature tests in this section have not yet been reviewed.
...