ACL and OAuth scopes (permissions: Agent/User vs. App)

[elf-pavlik]

TL;DR

1. OAuth Access Token Scope and Web Access Control seem complementary and addressing distinct concerns: agent/user permissions vs. app permissions.
2. IndieAuth could have somehow similar flow to WebID-TLS if Authorization Server for example issues JSON Web Tokens with URI of Agent/User in it (sub?) - similar to SAN in X.509 cert used by WebID-TLS, while adding capacity of using scopes.

After discussing this topic further with @fkooman I see one very important distinction to keep in mind:

• Web Access Control (used in SoLiD addresses concern of permissions which Agent/User (e.g. Person) has for given resource. In most cases the Resource Server will stay responsible for managing them.
• Access Token Scope addresses concern of permissions for SoftwareApplication (e.g. micropub client) to act on behalf of Agent/User

  SoLiD, Micropub, remoteStorage

• LDP/SoLiD use different resources - distinct URIs - to define ACL (Agent/User permissions) it doesn't seem to have any way of limiting scopes (App permisionss) - what particular software client can do with all those resources on agent's behalf.
• Micropub uses single endpoint (URI) for all managed resources and seems to assume that owner of the endpoint has 'super user' powers (Agent/User permissions) and no one else can access (in practice mostly modify, not sure about query) any of resources managed by it. Early work exist with experiments which use scopes (App permissions)
• remoteStorage, to my understanding uses different URIs for managed resources, and similar to Micropub it assumes single owner which has 'super user' powers (Agent/User permission) and uses scopes (App permissions) by mapping them to roots of hierarchical URL structure

seeAlso: https://github.com/aaronpk/Micropub/issues/11

WebID-TLS (X.509 SAN) & JWT sub

Resource Server could possibly use JSON Web Token sub parameter in a similar way as WebID-TLS uses X.509 Subject Alternative name to identify the Agent/User trying to access resources. In both cases verification would fetch agents web profile. WebID-TLS would get public key from there, while IndieAuth would 'follow its nose' via _tokenendpoint link relation and verify token by using public key announced by this endpoint to verify JWT signature. http://jwt.io/ For IndieAuth supporting authentication with client certificates, please see: http://indiecert.net

@skddc @michielbdejong @silverbucket @melvincarvalho @aaronpk @dissolve @deiu @bblfish

TODO: compare with http://manu.sporny.org/2014/credential-based-login/ & http://manu.sporny.org/2014/identity-credentials/ & http://manu.sporny.org/2013/sm-vs-jose/

[melvincarvalho]

I think this is putting the cart before the horse. When talking about permissions and auth, I think the framing is really important. To that end it needs to be said what is being authenticated. The problem we have had in the social web for 10 years, leading to non interop is that most people dont know.

• Is it a URI?
• Is it a flat string?
• Is it a composite key?
• Is it something else?

It's much easier to talk about permissions and auth once that first thing is clearly established and marked. SoLiD have a whole (short) spec devoted to this.

[elf-pavlik]

@dissolve re: https://github.com/aaronpk/Micropub/issues/11#issuecomment-108516126

I can hide those features in the UI or I risk my client not working with any other endpoint.

In similar way, client application, interacting with resource server which uses ACL, can leverage hypermedia controls if present, to add/remove possible actions in UI. For example:

• http://indiewebcamp.com/hypermedia

Will show you Create button if you loged in, or locked page will only show Edit button if you have admin privilege for that resource.

Similar if my API implements SuggestFriend Action, your UI can show you appropriate widget based on such hypermedia control, which may than use your contacts list for autocomplete. Otherwise you may need to use plain text message to send me a link to a friend you want to suggest me. In short, UI will depend on both set of permissions: Agent/User over resource & App to act on Agent/User behalf.

[dissolve]

I "can't" (typo on my part) adjust UI features unless i know what scopes mean.