Quorum was not reached.
Approve minutes of UMA telecon 2017-03-09: Deferred.
#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?
(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.
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.
AI: Eve: Send separate note to the WG proposing this and asking for feedback.
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)
Non-voting participants: