Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

UMA telecon 2017-04-13

Date and Time

Agenda

  • Roll call

  • Approve minutes of UMA telecon 2017-03-09 

  • Logistics:
    • The Apr 11 ad hoc (which was quorate) worked through #294 (Consider a proof-of-possession option for the RPT)
    • Concrete proposal for spec refactoring (#290 (Generality of RReg spec?) and #296 (Out-of-the-box profiling for tight AS-RS coupling)) may be ready for consideration in Apr 20 meeting
    • Let's see if we can work through the rest of the open substantive issues in this meeting
  • UMA V2.0 work:
    • 2016 roadmap / GitHub issues for V2.0/ dynamic swimlane
    • Core is up to 20 and RReg is up to 06 (WG drafts; no change)
    • #295 (When a requesting party needs to withdraw their access): This touches on downscoping and token revocation, and thus could use some analysis
    • #298 (Reconsider whether ticket should be on all redirect-back AS responses): Main issue seems to need no action, but a related issue came up about the appropriateness of not_authorized as an error that we could consider
    • #303 (Cleaning up the security considerations: JSON Usage): Possibly pass a quick eye over this one
  • AOB

Minutes

Roll call

Quorum was not? reached.

Approve minutes

Approve minutes of UMA telecon 2017-03-09: tbs

Logistics

  • The Apr 11 ad hoc (which was quorate) worked through #294 (Consider a proof-of-possession option for the RPT)
  • Concrete proposal for spec refactoring (#290 (Generality of RReg spec?) and #296 (Out-of-the-box profiling for tight AS-RS coupling)) may be ready for consideration in Apr 20 meeting
  • Let's see if we can work through the rest of the open substantive issues in this meeting

UMA V2.0 work

#295 (When a requesting party needs to withdraw their access):

The Token Revocation spec (a coarse-grained mechanism of positively rescinding one's granted access from the client side) "should work" as usual; in this case, the client would be acting on behalf of the RqP instead of the RO.

For any fine-grained recision, a la "I want to keep read access, but rescind write access" (or "I want to still get access to the trunk but rescind access to driving the car"), the client could simply ask for few scopes, but there's in-band way (OAuth or UMA) for the client to confirm that it then received the fewer scopes it wanted. The point of the issue is that Bob takes on accountability/responsibility/liability from the moment access is granted, whether or not he ever drives the car.

The general idea is that the juncture at which the technical artifact is issued has a corresponding agreement/contract. But if the client previously asked for "trunk" and "drive" scopes, but now asks for only "trunk", and the RS's documented pattern that it executes is to still always ask for "drive" scope, then our RequestedScopes set in that later calculation will still have "drive" in it because of the PermissionTicket portion. However, there's evidence from the client's request at the token endpoint that it wished to have fewer scopes. Is this enough to reduce Bob's accountability, if the token it gets back still has "drive" scope in it? This doesn't seem strong enough, but "fine-grained revocation" seems like a stretch goal for now anyway.

Does the Token Revocation spec (RFC 7009) work the same way for UMA? Justin says it should work the same, as the RPT is just an access token.

What about revoking the PCT? What's the motivation for revoking a PCT? They're useful/usable across RPTs, but we wouldn't want to revoke RPTs that were issued on the basis of some PCT. The point of token revocation generally is security hygiene, allowing a client to clean up after itself and let the AS record that the client did so. Justin suggests an (optional) method for leveraging the existing token revocation mechanism, providing some sort of "pct" keyword as a new token type hint. We'd have to add more IANA registry stuff. The AS is required not to say what it did in response to the revocation request, in order not to give an attacker with a stolen token TMI.

#298 (Reconsider whether ticket should be on all redirect-back AS responses):

We have errors that are identical on redirect-back (RqP/claims interaction endpoint) and the token request (client/token endpoint). On which errors should the AS produce a (rotated) ticket, and on which ones should the authorization process end?

Redirect-back: Thinking of how the client is going to respond ("What's my motivation?"), can we consolidate claims_submitted and request_submitted? We don't have enough experience to know if the difference is truly significant. In a way, all these options boil down to "continue" (or "don't continue")! Do we need authorization_state at all? Flipping the logic entirely, we could just pass an error if the client should just stop.

Since our claims interaction endpoint is the moral equivalent of the authorization endpoint, only for RqPs, it's way better for our OAuth alignment goal to sync with the authorization endpoint's error response.

Our proposal: Require the AS to use an error response according to Sec 4.1.2.1 as defined in OAuth (by reference).

Token request: Obviously, if the client gets a token successfully, it got a token and that ends the process. A "need info" means it needs to (has the opportunity to) continue the process in the next call to the token endpoint. Thus, same-process context is needed. A broken request message means the process ends. If the request is submitted and the client has nothing to do but it's all about the AS and RO doing something, the discussion in the issue is about how a ticket needs to be issued in order to correlate a (possibly much) later "polling" attempt by the client. Of course, the client could ignore and start a new authorization process.

Eve's argument about reusing invalid_grant for the "non-structural" error of not_authorized, which doesn't hand out a ticket, stopping the authorization process, is that reusing an existing OAuth error for something it doesn't truly mean is weird. Justin feels that since clients don't care and wouldn't change their behavior either way, why not reuse invalid_grant? Robert and Cigdem say that the only reason to have both is to provide extra information why it was a no. Robert: "If the information is not going to be used, it's not data. It's wasted." Of course, error_description could be used.

  • invalid_grant: no; state that a definitive failure, vs. a deliberate continuance of the process, uses this error (a change)
  • invalid_scope: no
  • request_submitted: yes (a change)
  • need_info: 
  • not_authorized: remove (a change)

AI: Eve: Send separate note to the WG proposing this and asking for feedback.

Attendees

As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)

  1. Domenico
  2. Eve
  3. Cigdem

Non-voting participants:

  • Robert
  • Justin
  • Ishan
  • Jin
  • Bjorn

Regrets:

  • tbs

 

  • No labels