Child pages
  • UMA V2.0 Disposition of Comments
Skip to end of metadata
Go to start of metadata

FINAL

Introduction

The User-Managed Access (UMA) Work Group's UMA V2.0 Draft Recommendations have undergone two Public Comment and IPR Review periods, the first 25 May 25 - 12 July 2017 and the second 28 Sep - 12 Nov 2017. This document records the group's disposition of comments received for the entire period 25 May to 12 Nov.

Key

  • 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 in the case of the first Public Comment period for most of the comments, or in the case of the final n issues, User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization revision 08. 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/rev 08 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 and to develop conforming UMA implementations 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 ReferenceIssue DescriptionSpecification Reference(s)Editorial/ TechnicalDispositionReport OutNotes
#326Improve and reorder definition of permission ticketGrant Sec 1.3EditorialCommit
Editorial improvement to a spec definition suggested, agreed by WG, and implemented.
#327Rationalize usage of "object" vs "parameter" labelingGrant Sec 3.3.6EditorialCommit
Simple editorial wording fix suggested, agreed by WG, and implemented.
#328Interpreting how client-contributed scopes are mapped to resources during authorization assessmentGrant Sec 3.3.4EditorialCommit
Interpretation issue raised; editorial enhancement removing ambiguity adopted by the WG.

#329

Typo: Fix cross-reference internal section targetGrant 7.4.1EditorialCommit
Incorrect cross-reference noted; fix applied without WG intervention required.
#330Typo: Fix cross-reference external specification targetFedAuthz Sec 9.2 EditorialNo change
Simple editorial correction suggested; fix was overcome by events (see #334 below).
#331Typo: Fix reference to item being registeredFedAuthz Sec 9.3EditorialCommit
Simple editorial correction suggested; fix applied without WG intervention required.
#332Test whether definitions of PCT are sufficientGrant (various)EditorialNo change
Interpretation question raised; WG decided to keep the existing wording.
#333Enhance redirect_user exampleGrant Sec 3.3.6EditorialCommit
Simple editorial enhancement requested; fix applied without WG intervention required.
#334Treating token introspection response claims as generic JWT claims in local token validation environmentsFedAuthz Sec 1, FedAuthz Sec 9.2EditorialCommit
Issue raised due to lack of implementation experience; editorial resolution adopted by WG involving removal of IANA registration request section for JWT claims (meaning that claims are not yet made available for use in a formal sense inside self-contained RPTs that the RS would validate locally vs. introspect at the AS).

#335a

Distinguish UMA versions of terms from OAuth onesGrant (various), FedAuthz (various)EditorialNo changeYesEditorial improvement requested; editor recommended no change.
#335bSpell out key UMA terms more fullyGrant (various), FedAuthz (various)EditorialCommitYesEditorial improvements requested; small edits applied without WG intervention required.
#335cSeparate out sequence diagrams according to resource owner-side vs requesting party-side interactionsGrant Sec 1.3EditorialCommitYesEditorial improvement to diagram(s) requested; editor recommended and implemented introductory text edits instead.
#335dSimplify sequence diagrams, e.g. to separate claims pushing from interactive claims gatheringGrant Sec 1.3EditorialCommitYesEditorial improvement to diagram(s) requested; added only clarification to existing single diagram after WG consultation.
#336Clarify that RPT takes a token_type hint of access_tokenFedAuthz Sec 5.1EditorialCommit
Editorial clarification requested, agreed by WG, and implemented.
#337aRationalize/complete definitions of token introspection response claimsFedAuthz Sec 5.1.1EditorialCommit
Clarification requested; WG determined an editorial improvement.
#337bClarify the situation with respect to client types in the UMA grantGrant Sec 3.3.3EditorialCommit
Clarification requested; WG determined an editorial improvement.
#337c,dCreate and document a concrete method to require and enable clients to pre-register claims redirection URIsGrant Sec 2, Grant Sec 3.3.2, Grant new Sec 7.3TechnicalCommit
Request for new mechanism for dynamic client registration mechanism and clarity; WG agreed. 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.
#337eTypo: Example that should show a response message is a request messageGrant Sec 3.3.3EditorialCommit
Simple editorial correction requested; fix applied without WG intervention required.
#337fClarify how permission requests with multiple permissions in them contribute to set mathGrant Sec 3.3.4EditorialCommit
Clarification requested; WG determined an editorial improvement.
 
#337gEnsure authorization servers apply the maximum security checks on permission ticketsGrant (various)EditorialCommit
Additional security considerations requested; WG agreed to add a form of security considerations that gives more discretion to the authorization server than was requested.
#338Typo: Example shows the wrong endpoint path componentFedAuthz Sec 3.2.1EditorialCommit
Simple typo correction requested; fixed without WG intervention required.
#339Clarify whether an array can be used for a request for a single permissionFedAuthz Sec 4.1EditorialCommit
Clarification requested; WG confirmed correct interpretation and clarification text.
#340A unique error should be available for a definitive policy-failed errorGrant Sec 3.3.6, Sec 7.4.1TechnicalCommit, commit, commit, commit
Change requested; WG reintroduced and renamed an UMA1 error code that was removed in Apr 2017: in UMA1 (see Core V1.0.1 Sec 3.5.4) was not_authorized and is now called request_denied.
#341The request_submitted error should be allowed to be terminal (no permission ticket)Grant Sec 3.3.6, Sec 5.6TechnicalCommit
Change requested to make the permission ticket optional on the AS response; WG made a different change, still requiring the ticket but 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).
#342Security considerations need to be made clearer and more to the point, especially Grant Sec 5.2Grant Sec 5EditorialCommit
 Clarification requested; WG determined an editorial improvement.
#343Refer to RFC 6749 token endpoint error codes specificallyGrant Sec 3.3.6EditorialCommit
Clarification requested; WG agreed an explicit reference to 6749 would be helpful.
#344Explain what to do if the client presents an invalid or expired claim tokenGrant Sec 3.3.6EditorialCommit
Clarification requested; WG confirmed the correct interpretation and clarification text: these conditions require one of the existing errors.
#345Explain what to do if the client presents a claim token in a format the authorization server can't handleGrant Sec 3.3.6EditorialCommit
Clarification requested; WG confirmed the correct interpretation and clarification text: this condition requires one of the existing errors.
#346ClientedRegistered scopes should not be a first-class set math citizenGrant Sec 3.3.4EditorialNo change
Clarification requested; commenter decided to close own issue without action.
#347The authorization server should be given discretion to determine if it's an error when the client requests a scope it did not pre-register forGrant Sec 3.3.6EditorialCommit
Change requested; WG broadened the authorization server's behavior, giving it discretion to report the requested error.
#348On the refresh flow, the authorization server should be given discretion to perform authorization assessmentGrant Sec 3.3.1, Sec 3.6, new Sec 6.1, FedAuthz Sec 1.4.1, Sec 8EditorialCommit
Change requested; WG did not make the change but clarified that no discretion is possible. Also confirmed error and non-error cases in the RPT upgrade flow, which is like UMA-specific refreshing.
#349Explain what to do if the client presents an invalid or expired RPT for upgrading(see above)EditorialCommit
Clarification requested; WG confirmed the correct interpretation and clarification text. (See #348 above for details.)
#350Explain what error code to return when CandidateGrantedScopes < RequestedScopesGrant Sec 3.3.4EditorialCommit, commitYesClarification requested; WG confirmed the correct interpretation and clarification text, resolving several inconsistencies in the authorization assessment normative text and incompleteness in the worked example.
#351Variety of editorial issues in FedAuthzFedAuthz (various)EditorialCommit
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.
#352The PAT is not needed for the permission and token introspection endpoints, so use client credentials insteadFedAuthz Sec 1.4.1, Sec 1.5EditorialCommit
Change requested; WG made some clarifications instead.
#354-1Explain what error code to return if the resource registration endpoint gets a request message with a bad/broken request bodyFedAuthz Sec 3.2TechnicalCommit
Change requested; editor, in collaboration with some WG participants, specified the HTTP 400 (Bad Request) status code and an optional new protection-API-level error code 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-2The PAT should definitively be a bearer tokenFedAuthz Sec 1.3TechnicalCommit
Change requested; editor, in collaboration with some WG participants, reintroduced an UMA1 requirement to support bearer PATs (see UMA V1.0.1 Core Sec 1.4, 'The authorization server is REQUIRED to support "bearer"') whose inadvertent removal might have caused interoperability problems.
#355Idea for the resource server to return an RPT directly rather than a permission ticket that enables a full UMA flowGrant Sec 3.2TechnicalNo change
This issue was submitted by a group participant intending for it to be an idea for a future extension, to be discussed at a later date, and the group accepted it on this basis.
#356Typo: Add missing code example portion(s)Grant Sec 3.3.6EditorialCommit
Simple editorial correction requested; fix applied without WG intervention required.
#357Clarify set math language by removing parenthetical "clarification"Grant Sec 3.3.4EditorialCommit
Clarification requested; WG confirmed the correct interpretation and action.
#358aConcern re the authorization server being a separate service, vs. the resource server, learning requesting party PIIGrant Sec 3.3.1, 3.3.23.3.4, and 6.2-No changeYesComment requested no specific change; WG interpreted it as questioning an underlying premise of UMA and declined to take action.
#358bConcern re claims being pushed by a client seeking access to a protected resource without authorization by the requesting partyGrant Sec 3.3.1, 3.3.2, 5.76.2EditorialCommit, commitYesIssue arose as a result of discussing alternative interpretations of #358. WG decided to add security and privacy considerations to address the concern.

Summary of Technical Changes

The following technical changes were made after the first Public Comment period. The decisions to make technical changes turned out to fall into one of two categories: reintroduce an UMA1 feature or introduce a feature that closely tracks the design of a feature already existing in OAuth or among its ecosystem of specifications. The first is important for cross-version feature parity and the second is important for the group's roadmap design priority of "simplify the protocol and make it work more like OAuth".

IssueDescriptionCategory
#337c,dAdded claims_redirect_uris OAuth Dynamic Client Registration metadata fieldOAuth
#340Reintroduced UMA1 not_authorized error code and renamed it to request_deniedUMA
#341Added interval parameter to request_submitted; design tracks OAuth Device Flow interval parameter OAuth
#354-1Added optional invalid_request error code to resource registration endpoint; design tracks OAuth and OAuth bearer token error codesOAuth
354-2Reintroduced UMA1 requirement for PAT as bearer token to be supportedUMA

It was determined that making these technical changes necessitated returning to a second Public Comment period.


  • No labels