Page Comparison

...

• Core 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 2: "It is OPTIONAL for the client credentials to be provided dynamically through [DynClientReg]); alternatively, they MAY use a static process."

Issues

1. Typo in Core Sec 1.4: s/absent/absence/

...

• Core 1.3.2: "The resource server presents one or more protected resource endpoints to the client; these endpoints are protected by the UMA profile of OAuth and require a requesting party token (RPT) with sufficient authorization data for access." (non-normative)
• Core 1.3.2: "This specification defines one RPT profile, call "bearer" (see Section 3.3.2), which is REQUIRED for the authorization server to support."
• Core 2: "Once a resource set has been placed under authorization server protection through the registration of a resource set description for it, and until such a description's deletion by the resource server, the resource server MUST limit access to corresponding resources, respecting authorization data associated with client-presented RPTs by the authorization server as appropriate."
• Core 3: "Each interaction (as part of getting authorization and access a resource) MAY be the last, if the client chooses not to continue pursuing the access attempt or the resource server chooses not to continue facilitating it."
• Core 3.1.1: "If the client does not present an RPT with the request, the resource server MUST return an HTTP 401 (Unauthorized) status code, along with providing the authorization server's URI in an "as_uri" property to facilitate authorization server configuration data discovery, including discovery of the endpoint where the client can request an RPT."
• Core 3.1.2: "If the client presents an RPT with its request, the resource server MUST determine the RPT's status (see Section 3.3) before responding. If the RPT is invalid, the resource server MUST return an HTTP 401 (Unauthorized) status code, along with providing the authorization server's URI in an "as_uri" property in the header, similarly to the case where no RPT was presented."
• Core 3.1.2: "If the RPT is valid but has insufficient authorization data for the type of access sought, the resource server SHOULD register a requested permission with the authorization server that would suffice for that scope of access (see Section 3.2), and then respond with the HTTP 403 (Forbidden) status code, along with providing the authorization server's URI in an "as_uri" property in the header, and the permission ticket it just received from the AM in the body in a JSON-encoded "ticket" property."
• Core 3.1.2: "If the RPT's status is associated with authorization data that is consistent with authorized access of the scope sought by the client, the resource server MUST give access to the desired resource."
• Core 3.1.2: "The resource server MUST NOT give access where the token's status is not associated with sufficient authorization data for the attempted scope of access."
• Core 3.2: "The (permission) ticket value MUST be securely random (for example, not merely part of a predictable sequential series), to avoid denial-of-service attacks."
• Core 3.2: "If the registration request is successful, the authorization server responds with an HTTP 201 (Created) status code and includes the Location header in its response as well as the "ticket" property in the JSON-formatted body."
• Core 3.2: "If the registration request is authenticated properly but fails due to other reasons, the authorization server responds with an HTTP 400 (Bad Request) status code and includes one of the following UMA error codes..."
• Core 3.3.2: "On receiving an RPT of the "Bearer" type in an authorization header from a client making an access attempt, the resource server MUST introspect the token by using the authorization server's token introspection endpoint. ... The authorization server responds with a JSON object with the structure dictated by [OAuth-introspection]."
• Core 3.4.1: "It (client) obtains an RPT by performing a POST on the RPT endpoint. ... The authorization server responds with an HTTP 201 (Created) status code and provides a new RPT."
• Core 3.4.1: "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."
• Core 3.4.2: "It (client) performs a POST on the authorization request endpoint, supplying its own AAT in the header and its RPT and the permission ticket in a JSON object with properties "rpt" and ticket", respectively."
• Core 3.4.2: "The authorization server MUST base the addition of authorization data to RPTs on user policies."

Issues

1. 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.
2. "User policies" isn't testable; how do we shore up this wording in FT-as-give-authz-data?
3. Need more rptbearer-specific tests?
4. Add claimoidc-specific tests?
5. Add optasc-specific tests?
6. 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.
7. Regarding FT-asrs-issueintrospect-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  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?
8. Regarding FT-rs-register-permission and FT-as-permissionoidc-ticket: Can the RS register a whole bunch of permissions at the same time?Regarding FT-as-oidc-client: This is sort of 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.