| Status | ||||
|---|---|---|---|---|
|
...
- Comment Reference: The GitHub repository issue number of the comment and possibly a reference to a subpart of that issue. All issues relevant to the Public Comment and IPR Review period use both the label "V2.0" and the label "public comment period". The content of all comments has been stored in GitHub.
- Issue Description: Characterization of the issue in a short phrase. May be different from the issue name in GitHub.
- Specification Reference(s): A reference such as "Grant Sec n.n" or "FedAuthz Sec n.n", indicating actual sections that were edited. "Grant" refers to User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization revision 05 and "FedAuthz" refers to Federated Authorization for User-Managed Access (UMA) 2.0 revision 05, the Draft Recommendations under review. Issues relevant to each specification were labeled "grant" and "fedauthz", respectively. Some new sections were added and some sections were rearranged in the course of editing, but only rev 05 section numbers are used so that commenter references will be normative.
- Editorial/Technical: Whether the comment involves an editorial change (a change to interpretive wording, generally minor) or a technical one (a change to normative language that requires substantive specification change). A label of "editorial" was applied to issues that appeared, at first blush, to be editorial. Note that applying these categories itself requires interpretation, and there is some gray area between them. Implementers seeking to understand changes from the pre-Public Comment period to the final Draft Recommendation and Recommendation stages are encouraged to study all changes carefully.
- Disposition: The Work Group's conclusion about the action to take in response to the comment. "Commit" links go to specific GitHub commits showing exact specification text changes.
- Report Out: Whether the commenter submitted comments through the official Public Comment period channel, and requires reporting back of the disposition. Kantara staff should take action on this column.
- Notes: Context that may be helpful for the Leadership Council.
| 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; discussed by several WG participants and consensus rapidly gained. | ||||
| #327 | Rationalize usage of "object" vs "parameter" labeling | Grant Sec 3.3.6 | Editorial | Commit |
| Simple editorial wording fix suggested; discussed by several WG participants and 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; discussed thoroughly by the WG and an 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 overcome by events (#334). | ||||
| #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; discussed thoroughly by the WG and an editorial resolution adopted by the WG involving removal of the IANA registration request section for the 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; discussed by several WG participants and 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 requires a 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; typo 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 the 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: was not_authorized, 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. | ||||
| #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 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 | Change requested; editor, in discussion with some WG participants, proposed and implemented an HTTP status code and optional UMA-level error code that tracks the design of OAuth and OAuth bearer token error codes. | |
| #354-2 | The PAT should definitively be a bearer token | FedAuthz Sec 1.3 | Editorial | Commit | Change requested; editor, in discussion with some WG participants, agreed that this corrected an interoperability oversight in having previously removed a requirement to support bearer PATs in UMA1. |