naming OAuth scopes

[elf-pavlik]

I find name post for the OAuth scope extremely confusing.

For example, most Micropub servers require clients to obtain the "post" scope in order to create posts. - http://indiewebcamp.com/micropub#Scope

'obtain the "post" scope in order to create posts'

Does it relate to

1. create from CRUD
2. type of a resource: a posting
3. HTTP POST, which in micropub include update and delete

Proposed by @dissolve edit, delete IMO suggest post == create (CRUD), similar mentioned in a spec post:video. Please notice recent removal of Post activity type from AS2.0 draft https://github.com/jasnell/w3c-socialwg-activitystreams/pull/122 as well as my similar issue raised in https://github.com/jasnell/w3c-socialwg-activitystreams/issues/88

In case above I would like to propose using well established CRUD terminology: create, read, update, delete possibly also write == create + update + delete

• http://indiewebcamp.com/scope

For example remoteStorage draft tries to define scopes as :r for HTTP GET and HEAD (read) or :rw for all HTTP verbs (write). I also allows use of '*' for any resource type. http://tools.ietf.org/html/draft-dejong-remotestorage-04#section-9

Web Access Control, used in SoLiD, makes distinction between: Read, Write, Append, Control https://www.w3.org/wiki/WebAccessControl#Modes_of_Access

The Control one reminds me of admin:* used by github.

Possibly we could find some common pattern with _mode(:resourcetype)?

@fkooman @skddc @michielbdejong @silverbucket @melvincarvalho

[elf-pavlik]

How about using URIs from AS2.0 Vocabulary for scope names of CRUD operations?

• http://www.w3.org/ns/activitystreams#Create
• http://www.w3.org/ns/activitystreams#Read
• http://www.w3.org/ns/activitystreams#Update
• http://www.w3.org/ns/activitystreams#Delete

@jasnell @oshepherd

If we need notion of resource types, we could just authorize access to different collections having distinct URIs (OAuth audience parameter?) e.g microblog, calendar, map, taskboard

[raucao]

Not sure what that could look like for RS.

[aaronpk]

I'm okay with using the terms "create read update delete" instead of "post". I'm not going to switch to full URIs.

[dissolve]

The other sugesting was to limit to categories, sort of like android permissions model. "contacts", "profile", "posts", etc.

[raucao]

The other sugesting was to limit to categories, sort of like android permissions model. "contacts", "profile", "posts", etc.

That's impossible for remoteStorage at least.

[aaronpk]

Yes, I fully expect some Micropub APIs to support category-based scope. This is also one of the reasons I am planning on making the scope list customizable during the authorization grant on indieauth.com. https://github.com/aaronpk/IndieAuth.com/issues/72

[elf-pavlik]

Earlier today I thought about ways to combine unambiguous mode (CRUD+) with unambiguous category. Maybe using just a Claims Set part of Unsecured JWTs could come helpful. Assuming as: prefix for http://www.w3.org/ns/activitystreams# and JSON-LD @type keyword (rdf:type)

{
  "@type": "as:Event",
  "as:verb": "as:Create"
}

becomes scope token eyJAdHlwZSI6ImFzOkV2ZW50IiwiYXM6dmVyYiI6ImFzOkNyZWF0ZSJ9

something maybe more familiar to IndieWeb community:

{
  "h": "event",
  "action": "create"
}

becomes scope token eyJoIjoiZXZlbnQiLCJhY3Rpb24iOiJjcmVhdGUifQ

http://jwt.io

While create:event in many ways looks simpler, using standard way of decoding JSON(-LD) could provide more powerful way of defining scopes. Feel free to consider this comment thinking out loud

[elf-pavlik]

I think action part of micropub scope (action:category), should at least match mp-action parameter, which also includes undelete, also maybe syndicate looks like a special case. BTW I already suggested reusing AS2.0 terms in #4 also with simple verb registry (e.g. https://w3id.org/verb ) we could take convention that part before optional : maps to such commonly defined verbs. Since it may include more verbs than CRUD (admin, syndicate, ?) possibly also worth coordinating common verb definitions with:

• https://www.w3.org/wiki/WebAccessControl#Modes_of_Access
• http://indiewebcamp.com/web-actions#action_do_verbs
• http://microformats.org/wiki/h-listing (p-action)
• http://www.w3.org/TR/activitystreams-vocabulary/#activity-types
• http://schema.org/docs/full.html#Action
• https://developer.github.com/v3/activity/events/types/
• ?

Or at least try not to use post, publish, create, add, new, update, edit, ზმნა, Глагол, צייטווארט etc. at random See also: https://github.com/w3c-social/social-vocab/issues/12

[aaronpk]

Elf, I appreciate the thoughts on this, but I don't think it's useful to try to make something up for this until there is more implementation experience.

I also suspect that individual Micropub endpoints are going to want to treat scope slightly differently on their own. Luckily clients and servers don't actually have to agree on scope. What I mean by that is I can make up my own list of scopes for my micropub endpoint at whatever granularity I want, and as long as my authorization server lets me adjust the scopes I'm granting to a client, the client doesn't care what scopes are ultimately granted and it will still work.

I think leaving scope out of the core spec is a good idea as it allows servers to experiment with it after there are more implementations.

[dissolve]

aaronpk. I would disagree, and don't close this so quickly.

Look at my MP client, ben.thatmustbe.me/new I am forced to not adjust for what scopes the user has actually allowed. I request scopes 'post', 'edit', and 'undelete'. and I would like to say that if they don't allow 'edit' or 'undelete' I can hide those features in the UI or I risk my client not working with any other endpoint. Because they might be using 'create' to cover all of those or 'manageposts' or something else, my UI cannot adjust to a list of permissions that could be anything.

I would say this is something that should be in the spec.

[aaronpk]

I realize there are benefits when the client and server agree on scope values, but I think there is value to allowing further experimentation with scope values by servers. I would rather define a very small set of known scope values in the core spec, and see what happens once there are more implementations.

[ghost]

https://tools.ietf.org/html/rfc6750#section-3

This also allows the WWW-Authenticate header to indicate which scopes are required for a particular action, e.g. if you try to create a new post on the MP endpoint it could return this header:

POST /micropub/
Content-Type: application/x-www-form-urlencoded

h=entry&content=fooooobaaarbazzz

HTTP/1.1 403 Forbidden
...
WWW-Authenticate: Bearer realm="mp", scope="fancypostscopevalueoftheday"

After that you re-request authorization with that particular scope added.

Of course it would be neat if we could just come up with a list of standard scopes, but is also fair to take some more time to figure out what is a good idea for scope and what not. JWT is definitely a bad idea, URLs maybe not so bad... If Google does it... :)

[elf-pavlik]

Let's forget JWT. URLs have very cool feature that they allow you to get more information about resource by simple HTTP GET. So for example common scopes can have Human Readable = multiple languages labels https://github.com/w3c-social/social-arch/issues/7

Showing strings in english language may work for small group of geeks but will not satisfy need of 'general population'. I would really like to hear about other possible ways of providing human readable = multilingual labels for scope tokens which app can display in UI.

seeAlso: http://www.w3.org/TR/activitystreams-vocabulary/#dfn-displayname

[dissolve]

@aaronpk. That's more what I'm talking about, a small set. But we still need to define that set.

[aaronpk]

Rather than make something up from scratch, the first step is to document existing behaviors. Let's document existing behaviors from sites that currently support scope so we have a better place to draw from. There is already a wiki page for collecting examples, so let's use that. http://indiewebcamp.com/scope

[elf-pavlik]

:+1: just added Google+

[ghost]

Another approach: the MP (Micropub) endpoints choose their AS (authorization server) and have to register with them to 'introspect' the Bearer token from the Micropub client. With the registration at the AS instead of only obtaining a token to be able to verify Bearer tokens also a list of scopes supported by the MP endpoint could be registered that could, in addition to the scopes requested by the MP client be shown to the user at authorization time.

Quill (https://quill.p3k.io/) wants your permission to access your Micropub 
endpoint (https://tuxed.net/micropub/): 

Please review the permissions you want to give to Quill:

Requested by Quill:
[x] post

Supported by your Micropub endpoint:
[x] Create (https://micropub.net/scope#create)
[x] Read (https://micropub.net/scope#read)
[ ] Update (https://micropub.net/scope#update)
[ ] Delete (https://micropub.net/scope#delete)

Please select the permissions you want to give. We will lie to Quill and tell 
them you authorized the 'post' scope.

[ Continue ] [ Reject ]

[aaronpk]

This is exactly the kind of experimentation I want to see :-)

We know that the user chooses their authorization server as well as the micropub endpoint, so it's entirely reasonable to assume the two can coordinate on this. I would love to see this implemented!