Versions Compared

Old Version 2

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

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

UMA telecon 2017-04-13

...

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: tbsDeferred.

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):

...

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.

...

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?

(The formal meeting ended and we kept going ad hoc.)

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.

...