...
Feature ID | Type | Description | Test ID | Type | Role | Description | Succeed | Fail |
---|---|---|---|---|---|---|---|---|
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 requirements | Fails |
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 data | Fails | |||
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 |
FT-rs-get-dyn-client-creds | opt | RS | RS interacts with AS to request and receive client credentials dynamically | RS gets client credentials dynamically | Fails | |||
FT-c-get-dyn-client-creds | opt | C | C interacts with AS to request and receive client credentials dynamically | C gets client credentials dynamically | Fails | |||
F-pat |
Historical supporting clauses:
F-pat:
- Sec 1.5: "oauth_token_profiles_supported REQUIRED. …. The AM is REQUIRED to support this profile, and to supply this string value explicitly. The AM MAY declare its support for additional access token profiles by providing a unique absolute URI in a string value in the array for each one." (This profile being the bearer token profile.)
- Sec 1.5: "oauth_grant_types_supported REQUIRED. …. Each string value MUST be one of the grant_type values defined in [OAuth2], or alternatively an extension grant type indicated by a unique absolute URI."
- Sec 1.5: "token_endpoint REQUIRED."
- Sec 1.5: "user_endpoint REQUIRED."
- Sec 2.3: "The host MUST use OAuth 2.0 [OAuth2] to obtain the protection API token."
- Sec 1.3: "The AM presents the following endpoints to the host as part of its protection API; these endpoints are OAuth-protected and require a PAT for access, for which the "protection" OAuth scope is required…"
- Sec 1.5: "resource_set_registration_endpoint REQUIRED. …. A PAT MUST accompany requests to this protected endpoint."
- Sec 2.4.3: "The host MUST use its valid PAT obtained previously to gain access to this endpoint." (This endpoint being resource_set_registration_endpoint.)
- Sec 3.2: "The host registers the permission using the POST method at the AM's permission registration endpoint, providing its PAT to get access to this endpoint."
F-aat:
...
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 scope | Fails | ||
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 | Fails | ||
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 scope | Fails | ||
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:
- Sec 2.4 intro: "Once the host has received a PAT, for any of the user's sets of resources that are to be protected by this AM, it MUST register these resource sets at the AM's registration endpoint."
- Sec 2.4.1: "Scope description documents MUST be accessible to AMs through GET calls made to these URI references" (These being scope URI references.)
- Sec 2.4.3: "The AM MUST present an API for registering resource set descriptions at a set of URIs with the structure "{rsreguri}/resource_set/{rsid}", where the PAT provides sufficient context to distinguish between identical resource set identifiers assigned by different hosts."
- Sec 2.4.3: "Following is a summary of the five registration operations the AM is REQUIRED to support…"
- Sec 2.4.3: "If the request to the resource set registration endpoint is incorrect, then the AM responds with an error message (see Section 4.2) by including one of the following error codes with the response…"
- Sec 2.4.3.1: "On successfully registering a resource set, the host MUST use UMA mechanisms to limit access to any resources corresponding to this resource set, relying on the AM to supply currently valid permissions for authorized access."
- Sec 2.4.3.1: "On successful registration, the AM MAY return a redirect policy URI to the host in a property with the name "policy_uri"."
- Sec 2.4.3.3: "On successful update, the AM MAY return a redirect policy URI to the host in a property with the name "policy_uri"."
- Sec 2.4.1: "Scope descriptions MAY contain extension properties that are not defined in this specification."
- Sec 2.4.1: "A host MUST list a resource set's available scopes using URI references (as defined in Section 2.4.2). The scopes available for use at any one host MUST have unique URI references so that the host's scope descriptions are uniquely distinguishable. A scope URI reference MAY include a fragment identifier. Scope descriptions MAY reside anywhere."
- Sec 2.4.2: "Resource set descriptions MAY contain extension properties that are not defined in this specification."
- Sec 2.4.2: "The AM SHOULD use the scope names and any icons defined as part of the referenced scopes in its user interface to assist the user in setting policies for protecting this resource set."
- Sec 2.4.2: "When a host creates or updates a resource set description (see Section 2.4.3), the AM MUST attempt to retrieve the referenced scope descriptions. It MAY cache such descriptions as long as indicated in the HTTP cache-control header for the scope description resource unless the resource set description is subsequently updated within the validity period. At the beginning of an authorizing user's login session at the AM, the AM MUST attempt to re-retrieve scope descriptions applying to that user whose cached versions have expired."
...