Allow changing the granted scopes

[sknebel]

It would be nice if the user could not only review, but also change the scopes granted to an application.

Example use cases

1. A Micropub endpoint that expects create scope, but an older client that requests post instead
2. (Dis-)allowing a client to upload files by having an extra scope for the media endpoint

UI

The basis could be checkboxes to remove any of the requested scopes. To add additional ones, there could either be a free-text field and/or several predefined options offered with checkmarks.

The latter would add additional configuration: the list of known scopes.

[aaronpk]

👍

You've seen my implementation of this right? I think there's a screenshot on https://indieweb.org/p3k

[Zegnat]

There is no default list and I would love to keep IndieAuth from having to define such a list. IndieAuth doesn’t (and shouldn’t) care what it is being used for. I am afraid that people would expect some sort of example or default if we offer a list configuration.

Checkboxes to specify which of the requested scopes you are will to grant gets a huge :+1: from me though.

A free-text field for defining additional scopes is trivial to add, and I am not opposed to that either. Just trying to come up with the right use-cases for it. Or if there is any.

[aaronpk]

Checkboxes to remove any of the requested scopes is a great start. I think the custom scope field would be useful in the case that someone has defined even more granular scopes on their endpoint that the client doesn't request. For example, I was thinking yesterday about adding a new update:own scope to mine which would allow the client to only update posts that it has created, not update other posts.

[aaronpk]

btw I'm planning on adding similar checkboxes and the text field to indieauth.com as part of renaming it: https://github.com/aaronpk/IndieAuth.com/issues/72

[Zegnat]

For example, I was thinking yesterday about adding a new update:own scope to mine which would allow the client to only update posts that it has created, not update other posts.

That’s great, but what would you expect the requesting app to do with that then? Say my app requests the update scope. If you don’t give it to me I will disable updating in my application. As I never requested update:own or even know it is a thing I will never check for that one.

While interesting, I am just wondering wether it is useful to return custom scopes unless you are both the developer of the requesting app and the system it wants access to. And if you are the developer of both, both end of the negotiation will already know to expect update:own and no custom scope field is needed.

[aaronpk]

It's more about setting the internal list of scopes for the token rather than necessarily returning something to the client. You'll notice on my authorization interface I have a separate list of "channels" which lets me limit where apps can post to on my site. This isn't implemented as "scope" and isn't returned at all to the client, it's just an internal thing. I think custom scopes would allow a similar mechanism for people to start experimenting with this kind of thing.

[sebsel]

I said something weird on IRC today, and although I won't actually do that, I like to that it's currently possible:

14:14 sebsel  but in the end, it's just the question of 'can I do this'?
14:16 sebsel  The app just hints what it thinks it might need.
14:16 sebsel  I can also use scopes in Dutch, like 'bewerk' for 'update'. I just need to 
              make sure to give the app the scope 'bewerk' if it asks for 'update'.
14:17 sebsel  It is my site that checks which operation is allowed by which app at 
              what point.

Aaronpk's update:own is in line with that idea: your site decides at which points in the flow a certain scope is needed, and your site gives you the option to decide which apps get which scopes. The app only suggests what it thinks it needs.

In the end, the app can just do it's thing, and respond to 403's correctly (hey Quill 😉). All your site can do is give a message and then it's up to the app to give that to the user.

I think "getting errors to the user" is a better thing to focus on than getting a list of defined scopes. But that's all out of scope for Selfauth of course.

[Zegnat]

Interesting. I was thinking clients might make use of the scopes because IndieAuth allows them to check exactly what scopes they were given. Returning the given scopes is part of the code verification step.

Maybe this sets an expectancy? It did for me. If we define that clients should not make us of it, I have no objections to sending completely custom scopes to them.