...
A test may additionally be of these types:
- "rptbearerrpt-bearer" (specific to the mandatory-to-implement "bearer" RPT profile)
- "claimoidcclaim-oidc" (specific to the optional OpenID Connect claim profile)
- "optascoptim-asc" (specific to the forthcoming optional AS=C optimization profile)
- "humanrqp" (specific to the claims-gathering flow for clients operated by end-users)
...
- Break down these feature tests into smaller chunks? What makes sense? The list of supporting clauses will be huge once we fill it in. Some candidates: MTI "bearer" RPT support vs. other profiles.
- "User policies" isn't testable; how do we shore up this wording in FT-as-give-authz-data?
- Need more rptbearer-specific tests?
- Add claimoidc-specific tests?
- Add optasc-specific tests?
- Regarding FT-rs-respect-authz-data: Is this truly a testable assertion, or is it in the realm of Binding Obs? Doublecheck what language we really have in the current spec about this need for "respecting" permissions. See Section 2 of the Core spec.
...
- Regarding FT-as-issue-rpt: Is it too implementation-specific that the spec says that "If the AAT provided in the header is the same as one provided for a previously issued still-valid RPT by this authorization server, the authorization server invalidates the old RPT and issues a new one." in Section 3.4.1? The AS could instead have refreshed the same RPT that had expired and give it back.
- Regarding FT-rs-introspect-rpt: The client currently has no way of knowing if the RPT is about to expire, and it could be more efficient if it could look this up through token introspection. Should we consider this for the spec?
- Regarding FT-rs-register-permission and FT-as-permission-ticket: Can the RS register a whole bunch of permissions at the same time?
- Regarding FT-as-oidc-client: This is sort of an implicit callout to the OpenID Connect interop tests. Do we even need this? Is anyone planning to test this for UMA1? See Section 3.5.1.1 for the list of things an AS has to do to conform to this claim profile.
- We have a new philosophical question: Even if the AS=C optimization profile is in use, is it mandatory-to-implement for the AS to present real and functional HTTPS endpoints for clients that "aren't it" (the same system entity) to use? If so, our various "req" feature tests below are true. If not, do we make them "opt" and "non-optim-asc" (the inverse of "optim-asc")? In any case, we should be sure to explicitly list the MUSTs that get turned off in this profile (and other such profiles). Maciej is thinking we may, after all, want to put health warnings next to each MUST – it might not be that onerous, and we will have done all the work anyway! Spec readers would otherwise be challenged.
| Test ID | Type | Role | Description | Success |
|---|---|---|---|---|
| FT-unprotected-resource | req | RS | RS responds to access request for unprotected or otherwise non-UMA-protected resource without including anything UMA-specific in the response | RS responds in non-UMA fashion |
| FT-rs-no-rpt | req | RS | RS responds to client not bearing an 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-get-rpt | req | C | Client presents valid AAT at AS's RPT endpoint to get RPT; if an existing RPT associated with this AAT was still valid, it is invalidated when the new RPT is issueds RPT endpoint to get RPT | Client qualifies for and gets new or refreshed RPT |
| FT-as-issue-rpt | req | AS | AS issues RPT in response to client's request for an RPT at the correct endpoint with a valid AAT; if an existing RPT associated with this AAT was still valid, it is invalidated when the new RPT is issued (see above for issue) | AS issues RPT |
| FT-c-rpt | req | C | C requests access to a resource with an RPT | |
| FT-rs-introspect-rpt | req, rpt-bearer | RS | RS presents a valid RPT at AS's token introspection endpoint to get token's status (see above for issue) | RS gets well-formed RPT status |
| FT-as-introspect-rpt | req | AS | AS returns RPT's status in response to RS request | AS returns well-formed RPT status |
| FT-rs-invalid-rpt | req | RS | RS responds to client bearing an invalid RPT with HTTP 401 and correct as_uri corresponding to to AS protecting the resource to which access was attempted | RS responds with HTTP 401 and as_uri |
| FT-rs-register-permission | req | RS | RS presents a valid PAT at AS's permission registration endpoint to register a requested permission that would suit is relevant for the type of access attempted by client (see above issue) | RS registers requested permission |
| FT-as-permission-ticket | req | AS | AS registers permission associated with correct resource owner and resource set and returns securely random permission ticket in response to RS registration of requested permission (see above issue) | AS returns permission ticket that is securely random |
| FT-rs-insufficient-perms | req, rptbearerrpt-bearer | RS | RS responds to client bearing a valid "bearer" profile RPT with that has insufficient permissions with HTTP 403, as_uri, and permission ticket corresponding to resource for which access was attempted | RS responds with HTTP 403, as_uri, and permission ticket |
| FT-c-add-authz-data | req | C | Client presents valid AAT, valid RPT, and permission ticket at AS's authorization endpoint to POST request that authorization data be associated with RPT | Client receives back normal success or error message |
| FT-as-deny-authz-data | req | AS | AS determines that the client should not get authorization data, and returns either an invalid_ticket error, an expired_ticket error, or a not_authorized_permission error | AS returns one of the errors |
| FT-as-give-authz-data | req | AS | AS associates new authorization data with the RPT that the client presented and responds with success, based on "user policies" ? | AS adds authorization data and responds with success |
| FT-as-need-claims | req, rptbearer | AS | AS indicates it needs requesting party claims to considering adding permission to "bearer" profile RPT | AS responds to the client with a need_claims error |
| FT-c-claims-redirect | req, humanrqp | C | Client redirects human requesting party to AS to provide claims, providing whatever data is required by the selected claim profile | AS redirects requesting party to AS |
| FT-as-oidc-client | opt, claim-oidc | AS | AS correctly acts as OpenID Connect relying party as defined by the OpenID Connect claim profile | AS acts correctly? |
| FT-rs-respect-authz-data | 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 | RS blocks and grants client's access according to RPT's current status |