UMA1 Interop Features and Feature Tests
Main UMA1 Interop Testing page | Participants and Solutions | Results | uma-dev list
| Table of Contents | ||||
|---|---|---|---|---|
|
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 specification, any other normatively referenced technical specifications, and the software entities that serve as protocol endpoints implementing these specifications. None relate to the Binding Obligations specification because that spec describes expected behaviors of operators and users of these endpoints, which makes them untestable for the purposes of an interop. 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.)
...
| ID | req/opt | Description | Success |
|---|---|---|---|
| FT-as-config-data | req | AS provides configuration data that conforms to specified formats and provides all required properties and values. | Data conforms and is complete
|
FT-as-config-endpt | req | 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 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 | Client 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 client and including handling of non-understood extension properties. | Client successfully accesses and parses AS config data |
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.
...
| ID | req/opt | Description | Success |
|---|---|---|---|
| FT-as-rsr | req | AS 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. | RS able to use all elements of resource set registration API |
| FT-rs-rsr | req | RS 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 issues errors for resource set registration 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 | 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 |
| FT-as-introspect | req | AS presents the token introspection endpoint, supporting only the POST method. | RS able to use token introspection endpoint |
| FT-rs-introspect | req | RS presents a valid RPT at AS's token introspection endpoint to get token's status. | RS gets well-formed RPT status |
| FT-as-reg-permissionperm | req | AS presents a permission registration endpoint that enables RS to register permission associated with correct resource owner, resource set, and scopes, and returns securely random permission ticket in response to RS registration of requested permission. | AS returns permission ticket that is securely random |
| FT-rs-reg-permissionperm | req | RS presents a valid PAT, and valid previously registered resource set and scope information, at AS's permission registration endpoint to register a requested permission that is relevant for the type of access attempted by client. | RS registers requested permission |
...
| ID | req/opt | Role | Description | Success | |
|---|---|---|---|---|---|
| FT-unprotectedrs-no-resourcerpt | req | RS | RS responds to client not bearing an RPT with HTTP 401 and correct as_uri corresponding to AS protecting the resource to access request for unprotected or otherwise non-UMA-protected resource without including anything UMA-specific in the responsewhich access was attempted. | RS responds in non-UMA fashionwith HTTP 401 and as_uri | |
| FT-rs- | noinvalid-rpt | req | RS | RS responds to client not bearing an invalid RPT with HTTP 401 and correct as_uri corresponding to AS protecting the resource to which access was attempted. | RS responds with HTTP 401 and as_uri |
| FT-c-rpt | req | C | C requests access to a resource by providing a correctly formed and located RPT. | ||
| FT-rs-insufficient-authzperm | req | RS | RS responds to client bearing a valid "bearer" profile RPT that has insufficient permissions with HTTP 403, as_uri, and permission ticket corresponding to resource for which access was attempted. NOTE: Conducting this test depends on RS-specific API and scope details. | RS responds with HTTP 403, as_uri, and permission ticket | |
| FT-rs-respect-authz | req | RS | RS limits access to resource that is currently under protection at an AS for which a valid RPT with valid authorization data has not been presented by a client. NOTE: Conducting this test depends on RS-specific API and scope details. | RS blocks and grants client's access according to RPT's current status |
Feature tests for "claims"
TBS.