...
- 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.
| Test ID | Type | Role | Description | Success |
|---|---|---|---|---|
| FT-unprotected-resource | req | RS | RS responds to access request for unprotected resource without including anything UMA-specific in the response | RS responds in non-UMA fashion |
| FT-no-rpt | req | RS | RS responds to client not bearing an RPT with HTTP 401 and correct as_uri corresponding to 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 issued | 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 | AS issues RPT |
| FT-rs-introspect-rpt | req | RS | RS presents valid RPT at AS's token introspection endpoint to get token's status | 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 invalid RPT with HTTP 401 and correct as_uri corresponding to resource to which access was attempted | RS responds with HTTP 401 and as_uri |
| FT-rs-register-permission | req | RS | RS presents valid PAT at AS's permission registration endpoint to register a requested permission that would suit for the type of access attempted | 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 | AS returns permission ticket that is securely random |
| FT-rs-insufficient-perms | req, rptbearer | RS | RS responds to client bearing valid bearer RPT with 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" 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-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 |