UMA1 Interop Features and Feature Tests

NOTE: This page is very much in progress.

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.

F-as-config: AS makes available its configuration data in the correct form at the correct location

Supporting clauses	Test ID	Type	Role	Description	Success condition
Core 1.4: "The authorization server MUST provide configuration data in a JSON [RFC4627] document that resides in an /uma-configuration directory at at its hostmeta [hostmeta] location." Core 1.4: "Authorization server configuration data MAY contain extension properties that are not defined in this specification." Core 1.4: "All endpoint URIs SHOULD require the use of a transport-layer security mechanism such as TLS. The authorization server MUST declare all of its endpoints in its configuration data." (Also all the REQUIREDs/MUSTs and MAYs appearing in Core Sec 1.4 regarding the JSON format for AM configuration data.) Core 2: "The resource owner, resource server, and authorization server perform the following actions to put resources under protection. This list assumes that the resource server has discovered the authorization server's configuration data and endpoints as needed." (non-normative) RSR 1.3: "If the authorization server declares its endpoints and any other configuration data in a machine-readable form, for example [OAuth-linktypes] or [OAuth-meta], it SHOULD convey its resource set registration endpoint in this fashion as well." 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

F-dyn-client-reg: AS supports generating dynamic client credentials and RS and client support getting them

Supporting clauses

Test ID

Type

Role

Description

Success condition

Core 1.4: "dynamic_client_endpoint - OPTIONAL. The endpoint to use for performing dynamic client registration. Usage is defined by [DynClientReg]. The presence of this property indicates authorization server support for the dynamic client registration feature and its absent indicates a lack of support."
Core 2: "It is OPTIONAL for the client credentials to be provided dynamically through [DynClientReg]); alternatively, they MAY use a static process."

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

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

F-pat: AS successfully issues PAT to RS for use at AS's protection API

Supporting clauses	Test	Type	Role	Description	Success condition
Core 1: "To accomplish this protection, the authorization server presents a protection API ("C") to the resource server. This API is OAuth-protected and requires a protection API token (PAT) for access." (non-normative) Core 1.3.1: "An entity seeking protection API access MUST request the scope "http://docs.kantarainitiative.org/uma/scopes/prot.json", and an access token with at least this scope is called a protection API token (PAT). ... 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: "pat_profiles_supported - REQUIRED." Core 1.4: "pat_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 (introspection_endpoint) protected endpoint." Core 1.4 : "A valid PAT MUST accompany requests to this (resource_set_registration_endpoint) protected endpoint." Core 1.4 : "A valid PAT MUST accompany requests to this (permission_registration_endpoint) protected endpoint." Core 3.2: "The resource server MUST provide its valid PAT in order to get access to (permission_registration_endpoint) endpoint." Core 3.3.1: "The authorization server MUST OAuth-protect this (introspection_endpoint) endpoint and require a PAT from the resource server for access to it." 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

F-aat: AS successfully issues AAT to Client for use at AS's authorization API

Supporting clauses	Test	Type	Role	Description	Success condition
Core 1: "The (authorization) API is OAuth-protected and requires an authorization API token (AAT) for access." (non-normative) 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."	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

F-rsr: RS registers resource sets at AS in order to put them under AS protection

Supporting clauses	Test	Type	Role	Description	Success condition
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?	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

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."