Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
UMA does not facilitate chatter reduction at the RS #282
One of the main criticisms of UMA that I have heard is the degree of chatter sending the Client back and to between the RS and AS.
The interaction at the RS could reduce that chatter by not repeating permission tickets for scopes that have previously been turned down at the AS. However, because an RS cannot link a particular RPT to a previously registered ticket, it can't tell if it's registered for a permission before so only has a choice to resubmit in the hope that it might get approval next time around.
There are two ways that this could be fixed - either (a) make it possible for the introspection of the RPT to include what resource-scope combinations have been denied (perhaps along with the time this was done so that the RS can decide whether it wants to try again), as well as those approved, or (b) make it possible for the introspection to include a list of permission tickets that had been "cashed in". In both cases this would be returned for that RPT, and any previous RPTs that were absorbed into that RPT.
In UMA telecon 2017-02-23, we discussed this. There's actually a wider range of possibilities. The partial-results mechanism puts some control into the AS's hands, in that it could actually produce an authorization failure before the RS even gets to a decision point. And today in OAuth, if the client has failed, that is a signal for it to (possibly) do something different, like show an error to the user.
And the RS already has the option to error the client on the nth try to access the same thing, and not pump it through an UMA flow.
Justin reminds us to do a cost-benefit analysis; is adding a complex optimization valuable in terms of adding enough benefit?
Cigdem asks what the RS would learn: Would be not to add the additional scopes into the permission ticket? Eve's suspicion (not borne out by real-world practice yet, but "static-ness" is the the way the world trends) is that permission requests will be a static pattern vs. dynamic; see our GDoc analysis. And Cigdem asks how/why would an RS unlearn behavior based on a single client's signals? It seems like RS's in an ecosystem have more power ("juice") than clients. RS's write the APIs, and clients just write to them.
We have rough consensus to keep the current design as it is, and invite James to comment on these aspects to see if hearts and minds can be changed.
I'm not sure I agree that this is the case - the RS gets no context on each request - it can't distinguish request 1 for resource A from request 10.
Ultimately I'm trying to describe the UMA equivalent of the optional
That said, I have some sympathy for Justin's question:
Personally I think the answer is yes, but I can live with being shouted down :)
I'm not sure I understand the penultimate paragraph, sorry.
If my memory serves me right, the paragraph in question is a result of considering how the RS should act on the additional ticket-based information from RPT introspection.
Indeed, RS can use this information to “learn" which scopes not to add to client’s ticket because AS refuses them. Then RS would not repeat over and over such scopes in its ticket request.
What happens, at some instance, RO goes and changes the policy, and now AS can accept those scopes. How does RS “unlearn” the rule “Do not ask for scope a, b, c” for that particular client and it’s particular resource request?
Right, got it. Yes, the RS would have to be more intelligent than just always not bothering to add those scopes. When first discussed on the call I suggested that you would also put the timestamp of each declined permission so that the RS could make an informed decision about ignoring and trying again anyway.…
On 28 February 2017 at 10:33, ciseng ***@***.***> wrote: If my memory serves me right, the paragraph in question is a result of considering how the RS should act on the additional ticket-based information from RPT introspection. Indeed, RS can use this information to “learn" which scopes not to add to client’s ticket because AS refuses them. Then RS would not repeat over and over such scopes in its ticket request. But: Does RS need to learn new rules per client per resource/RO per AS? What happens, at some instance, RO goes and changes the policy, and now AS can accept those scopes. How does RS “unlearn” the rule “Do not ask for scope a, b, c” for that particular client and it’s particular resource request? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#282 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6kNmOO1qvACmI6EXE7JKLiTtJuQ8XPks5rg_gQgaJpZM4MKOII> .
Per UMA ad hoc telecon 2017-03-06: The key “business ecosystem” question is: Which way would we want to bet on whether an API publisher would be willing to request different permissions dynamically? Eve and Justin are pretty certain they wouldn’t. Justin is concerned about greater and greater complexity of the proposal, and hence premature optimization. The RS would need to keep tracking more information in order to optimize others’ experience.
Are we right in thinking that, since we’re talking about enriching the information sent to the RS through a JSON format, this could be an experimentation that grows into a V2.x addition? We believe so. So there’s room to play with this later if we discover pain in some deployments.
Let’s close without action for now, but anyone could take it up on their own initiative at any time if they see the need. Let’s create a label for all the potential extension work.