Child pages
  • UMA V2.0 Disposition of Comments

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 changeYesPending: Comment 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.23.3.4, and 6.2EditorialCommit TBS (pending)YesPending: Issue arose as a result of discussing alternative interpretations of #358. WG decided to add security and privacy considerations to address the concern.

...