Page Comparison

UMA1 Interop Features and Feature Tests

...

NOTE: This page is very much in-progress. The full draft set of features and feature tests is attached.

The features and

Main UMA1 Interop Testing page | Participants and Solutions | Results

The feature tests provided below are historical. We are redesigning them in light of feedback from the OpenID Connect interop and conformance testing process and Roland Hedberg's UMA test suite implementation process. The tests below may be inaccurate with respect to UMA V1.0 Candidate specs, as they date from the pre-V0.9 era.

...

These feature tests relate exclusively to the core protocol specspecification, any other normatively referenced specstechnical specifications, and the software components entities that serve as protocol endpoints implementing these specifications. None relate to the Binding Obligations document specification because this document that spec describes expected behaviors of operators and users of these endpoints, which makes them untestable for the purposes of an interop.

...

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

...

 Feature tests are marked as either required (req) or optional (opt) based on the optionality of the underlying spec clauses they're derived from, where req is for all testable MUST/REQUIRED clauses and opt is for all other testable clauses. We have not yet defined what "full conformance" means in any formal sense. (A few untestable clauses do appear in the technical specifications.)

A feature test identifier has three parts, separated by hyphens. Every identifier starts with FT. The second part indicates the software entity being tested: AS, RS, or C. The third part, which may have embedded hyphens, describes the nature of the test. The supporting clauses in the technical specifications have been classified using feature "tags". The tests are grouped under primary feature tags for ease of test result reporting.

Feature tests for "config"

Machine-readability of entity capabilities and constraints. 

Feature tests for "dynreg"

Client registration of resource servers (which are clients of the AS's protection API) and clients of resource servers (which are also clients of the AS's authorization API) at run time when services have not "met" before a resource owner or requesting party forces the issue.

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:

• 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."
• Sec 1.3: "The AM presents the following endpoint to the requester as part of its authorization API; this endpoint is OAuth-protected and requires an AAT for access, for which the "authorization" OAuth scope is required…"
• Sec 3.4.4: "The requester performs a POST on the RPT endpoint, supplying its own AAT in the header in order to gain access to the RPT endpoint."

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

Feature tests for "pat"

 "Protection of the protection API" at the authorization server, and the association made between the authorization server, resource server, and resource owner as a result of protection API token (PAT) issuance.

Feature tests for "aat"

"Protection of the authorization API" at the authorization server, and the association made between the authorization server, client, and requesting party as a result of authorization API token (AAT) issuance.

Feature tests for "protapi"

RS-AS communication through the protection API and its various endpoints.

Feature tests for "authzapi"

C-AS communication through the authorization API and its various endpoints.

Feature tests for "access"

C-RS communication through the UMA-protected resource interface for the purpose of attempting and granting or denying access.

Feature tests for "claims"

TBS.