Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UMA does not facilitate chatter reduction at the RS #282

Open
mrpotes opened this Issue Feb 23, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@mrpotes
Copy link

commented Feb 23, 2017

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.

@xmlgrrl xmlgrrl added core V2.0 labels Feb 23, 2017

@xmlgrrl

This comment has been minimized.

Copy link

commented Feb 23, 2017

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.

@mrpotes

This comment has been minimized.

Copy link
Author

commented Feb 27, 2017

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.

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 scope attribute of the token response in OAuth. In OAuth, the client makes a request and gets told in the response what scopes it was given (if not the full set requested. In UMA that is not possible, as it is really the RS that requests the scope for the RqP on behalf of the Client. It is the RS that needs the context of what it asked for and what it got, but because of the disconnected nature of the RS requests, this needs to be something that is given to the RS as it can't join the dots (unlike in the request-response connection that is possible in OAuth). It doesn't make any sense to tell the Client about these resource-based scopes because the client doesn't know how the resource IDs map to requested URLs.

That said, I have some sympathy for Justin's question:

is adding a complex optimization valuable in terms of adding enough benefit?

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.

@jricher

This comment has been minimized.

Copy link

commented Feb 27, 2017

@mrpotes The RS is getting context in this case -- it's getting an RPT that isn't good enough yet. This is rather different than the client not sending any RPT, which bootstraps the process.

@ciseng

This comment has been minimized.

Copy link

commented Feb 28, 2017

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?

@mrpotes

This comment has been minimized.

Copy link
Author

commented Feb 28, 2017

@xmlgrrl xmlgrrl added the extension label Mar 8, 2017

@xmlgrrl

This comment has been minimized.

Copy link

commented Mar 8, 2017

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.

@xmlgrrl xmlgrrl closed this Mar 8, 2017

@xmlgrrl xmlgrrl removed the V2.0 label Mar 15, 2017

@xmlgrrl xmlgrrl reopened this Mar 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.