Status | ||||
---|---|---|---|---|
|
This document records the User-Managed Access (UMA) Work Group's disposition of comments received since the beginning of the 25 May 25 - 12 July 2017 Public Comment and IPR Review period for the UMA V2.0 Draft Recommendations. (The WG continued to accept comments, mostly from WG participants, past the official end of the period. Late comments from non-participants resulted in only editorial changes.)
...
Comment Reference | Issue Description | Specification Reference(s) | Editorial/ Technical | Disposition | Report Out | Notes |
---|---|---|---|---|---|---|
#326 | Improve and reorder definition of permission ticket | Grant Sec 1.3 | Editorial | Commit | Editorial improvement to a spec definition suggested; consensus rapidly gained. | |
#327 | Rationalize usage of "object" vs "parameter" labeling | Grant Sec 3.3.6 | Editorial | Commit | Simple editorial wording fix suggested; consensus rapidly gained. | |
#328 | Interpreting how client-contributed scopes are mapped to resources during authorization assessment | Grant Sec 3.3.4 | Editorial | Commit | Interpretation issue raised; editorial enhancement removing ambiguity adopted by the WG. | |
#329 | Typo: Fix cross-reference internal section target | Grant 7.4.1 | Editorial | Commit | Incorrect cross-reference noted; fix applied without WG intervention required. | |
#330 | Typo: Fix cross-reference external specification target | FedAuthz Sec 9.2 | Editorial | No change | Simple editorial correction suggested; fix was overcome by events (see #334 below). | |
#331 | Typo: Fix reference to item being registered | FedAuthz Sec 9.3 | Editorial | Commit | Simple editorial correction suggested; fix applied without WG intervention required. | |
#332 | Test whether definitions of PCT are sufficient | Grant (various) | Editorial | No change | Interpretation question raised; WG decided to keep the existing wording. | |
#333 | Enhance redirect_user example | Grant Sec 3.3.6 | Editorial | Commit | Simple editorial enhancement requested; fix applied without WG intervention required. | |
#334 | Treating token introspection response claims as generic JWT claims in local token validation environments | FedAuthz Sec 1, FedAuthz Sec 9.2 | Editorial | Commit | Issue raised due to lack of implementation experience; editorial resolution adopted by WG involving removal of IANA registration request section for JWT claims. | |
#335a | Distinguish UMA versions of terms from OAuth ones | Grant (various), FedAuthz (various) | Editorial | No change | Yes | Editorial improvement requested; editor recommended no change. |
#335b | Spell out key UMA terms more fully | Grant (various), FedAuthz (various) | Editorial | Commit | Yes | Editorial improvements requested; small edits applied without WG intervention required. |
#335c | Separate out sequence diagrams according to resource owner-side vs requesting party-side interactions | Grant Sec 1.3 | Editorial | Commit | Yes | Editorial improvement to diagram(s) requested; introductory text edits made instead. |
#335d | Simplify sequence diagrams, e.g. to separate claims pushing from interactive claims gathering | Grant Sec 1.3 | Editorial | Commit | Yes | Editorial improvement to diagram(s) requested; added only clarification to existing single diagram after WG consultation. |
#336 | Clarify that RPT takes a token_type hint of access_token | FedAuthz Sec 5.1 | Editorial | Commit | Editorial improvement requested; WG consensus rapidly gained. | |
#337a | Rationalize/complete definitions of token introspection response claims | FedAuthz Sec 5.1.1 | Editorial | Commit | Clarification requested; WG determined an editorial improvement. | |
#337b | Clarify the situation with respect to client types in the UMA grant | Grant Sec 3.3.3 | Editorial | Commit | Clarification requested; WG determined an editorial improvement. | |
#337c,d | Create and document a concrete method to require and enable clients to pre-register claims redirection URIs | Grant Sec 2, Grant Sec 3.3.2, Grant new Sec 7.3 | Technical | Commit | Request for new mechanism for dynamic client registration mechanism and clarity; WG agreed. Mechanism The new metadata field, claims_redirect_uris , tracks the design of a similar metadata field, redirect_uris , already defined by RFC7591 and registered in the OAuth Dynamic Client Registration Metadata Registry. The new metadata field requires a new IANA registration request to IANA. | |
#337e | Typo: Example that should show a response message is a request message | Grant Sec 3.3.3 | Editorial | Commit | Simple editorial correction requested; fix applied without WG intervention required. | |
#337f | Clarify how permission requests with multiple permissions in them contribute to set math | Grant Sec 3.3.4 | Editorial | Commit | Clarification requested; WG determined an editorial improvement. | |
#337g | Ensure authorization servers apply the maximum security checks on permission tickets | Grant (various) | Editorial | Commit | Additional security considerations requested; WG agreed to add a form of security considerations that gives more discretion to the authorization server than was requested. | |
#338 | Typo: Example shows the wrong endpoint path component | FedAuthz Sec 3.2.1 | Editorial | Commit | Simple typo correction requested; fixed without WG intervention required. | |
#339 | Clarify whether an array can be used for a request for a single permission | FedAuthz Sec 4.1 | Editorial | Commit | Clarification requested; WG confirmed correct interpretation and clarification text. | |
#340 | A unique error should be available for a definitive policy-failed error | Grant Sec 3.3.6, Sec 7.4.1 | Technical | Commit, commit, commit, commit | Change requested; WG ultimately reintroduced ( and renamed ) an UMA1 error code that was previously removed: in UMA1 (see Core V1.0.1 Sec 3.5.4) was not_authorized , and is now called request_denied . | |
#341 | The request_submitted error should be allowed to be terminal (no permission ticket) | Grant Sec 3.3.6, Sec 5.6 | Technical | Commit | Change requested; WG made a different change, adding an optional new interval polling hint feature. The design of the new parameter tracks the design of a similar parameter in the OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (see Sec 3.2). | |
#342 | Security considerations need to be made clearer and more to the point, especially Grant Sec 5.2 | Grant Sec 5 | Editorial | Commit | Clarification requested; WG determined an editorial improvement. | |
#343 | Refer to RFC 6759 token endpoint error codes specifically | Grant Sec 3.3.6 | Editorial | Commit | Clarification requested; WG confirmed the correct interpretation and clarification text. | |
#344 | Explain what to do if the client presents an invalid or expired claim token | Grant Sec 3.3.6 | Editorial | Commit | Clarification requested; WG confirmed the correct interpretation and clarification text. | |
#345 | Explain what to do if the client presents a claim token in a format the authorization server can't handle | Grant Sec 3.3.6 | Editorial | Commit | Clarification requested; WG confirmed the correct interpretation and clarification text. | |
#346 | ClientedRegistered scopes should not be a first-class set math citizen | Grant Sec 3.3.4 | Editorial | No change | Clarification requested; commenter decided to close own issue without action. | |
#347 | The authorization server should be given discretion to determine if it's an error when the client requests a scope it did not pre-register for | Grant Sec 3.3.6 | Editorial | Commit | Change requested; WG gave the authorization server discretion to report the requested error. | |
#348 | On the refresh flow, the authorization server should be given discretion to perform authorization assessment | Grant Sec 3.3.1, Sec 3.6, new Sec 6.1, FedAuthz Sec 1.4.1, Sec 8 | Editorial | Commit | Clarification requested; WG confirmed the correct interpretation and clarification text. | |
#349 | Explain what to do if the client presents an invalid or expired RPT for upgrading | (see above) | Editorial | Commit | Clarification requested; WG confirmed the correct interpretation and clarification text. (See #348 above for details.) | |
#350 | Explain what error code to return when CandidateGrantedScopes < RequestedScopes | Grant Sec 3.3.4 | Editorial | Commit, commit | Yes | Clarification requested; WG confirmed the correct interpretation and clarification text. |
#351 | Variety of editorial issues in FedAuthz | FedAuthz (various) | Editorial | Commit | Variety of editorial comments, typo corrections, and the like made; implemented without WG intervention required. Note that the original form of the text in Sec 3.2, since corrected, could have led implementers astray, implying that a field was required when it was clear in a different context (Sec 3.2.4) that the field would not appear. | |
#352 | The PAT is not needed for the permission and token introspection endpoints, so use client credentials instead | FedAuthz Sec 1.4.1, Sec 1.5 | Editorial | Commit | Change requested; WG made some clarifications instead. | |
#354-1 | What should the AS do if the resource registration endpoint gets a request message with a bad/broken request body? | FedAuthz Sec 3.2 | Technical | Commit, TBS | Change requested; editor, in collaboration with some WG participants, proposed and implemented an HTTP specified the HTTP 400 (Bad Request) status code and an optional new UMAprotection-API-level error code that invalid_request . This error code tracks the design of the similar OAuth (RFC 6749 Sec 4.1.2.1) and OAuth bearer token (RFC 6750 Sec 3.1) error codes. | |
#354-2 | The PAT should definitively be a bearer token | FedAuthz Sec 1.3 | Technical | Commit | Marginally technical change Change requested; editor, in collaboration with some WG participants, agreed that change corrects an interoperability oversight in having previously removed a reintroduced an UMA1 requirement to support bearer PATs in UMA1(see UMA V1.0.1 Core Sec 1.4, 'The authorization server is REQUIRED to support "bearer "') whose removal caused interoperability problems. |