Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Features and Feature Tests for the UMA1 Interop

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.

Table of Contents

Features and tests that are new for UMA1 interop

Feature IDTypeDescriptionTest IDTypeRoleDescriptionSucceedFail
F-as-configreq

AS makes available its configuration data in the correct form at the correct location. Supporting clauses:

  • Core Sec 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 Sec 1.4: "Authorization server configuration data MAY contain extension properties that are not defined in this specification."
  • Core Sec 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 (see Section 1.4)."
  • (Also all the REQUIREDs/MUSTs and MAYs appearing in Core Sec 1.4 regarding the JSON format for AM configuration data.)
  • RSR Sec 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-datareqASAS provides configuration data that conforms to specified formatData conforms to format requirementsFails
FT-as-config-endptsoptASAS makes config data available through SSL/TLS-protected URLAS config data endpoint uses https: scheme and RS or client is able to validate AS's certificateFails
FT-rs-get-config-datareqRSRS 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 propertiesRS successfully accesses and parses AS config dataFails
FT-c-get-config-datareqCClient 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 propertiesClient successfully accesses and parses AS config dataFails
F-dyn-client-regopt

AS supports generating dynamic client credentials and RS and client support getting them. Supporting clauses:

  • Core Sec 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 Sec 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-regoptASAS config data "dynamic_client_endpoint" property is non-nullAS config data "dynamic_client_endpoint" property has a valid URL value for a DynClientReg endpointFails
FT-rs-get-dyn-client-credsoptRSRS interacts with AS to request and receive client credentials dynamicallyRS gets client credentials dynamicallyFails
FT-c-get-dyn-client-credsoptCC interacts with AS to request and receive client credentials dynamicallyC gets client credentials dynamicallyFails
         

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

...