Proposal: scope tags in WAC for fine-grain user control of app privilege

[zenomt]

This proposal is to replace the "trusted apps" mechanism, and to augment the acl:origin mechanism in WAC, to allow resource owners to control the access different of their apps have to their different resources, by introducing the notions of

1. access scopes (identified by tag patterns) for access modes for resources; and
2. a mapping from apps to tag patterns.

The proposal allows each user to have independent mappings of apps to tag patterns, provided the resource server is configured to enforce the visiting users' app access preferences.

If this proposal resonates with folks, I'll prepare a more formal specification as a PR.

Assumptions

• access control to resources belongs to the resource owner/controller
• access control is interpreted and enforced by the resource server
• a user should be able to use whatever app she wishes to access resources
• a (determined) user can lie to a resource server about the identity of the app she's using
  • corollary: a resource server can't force a (determined) user to use (or to not use) any particular app
• an app can't lie about its identity (specifically, it can't impersonate another app) without the help and approval of the user and her software agents (including her trusted web browser and/or trusted identity provider), or without the collusion (or malfunction) of the app being impersonated
• a resource owner/controller might wish to allow her own access for some classes of resources only to a subset of apps she uses, and to allow different apps access to different classes of resources
• a resource owner/controller might wish to allow other users to make independent choices of what apps are allowed access to different classes of resources (the classes assigned by the resource owner)
• the classifications of resources on one server by an owner are independent of classifications by other owners on other servers
• an app the user is using, by default, shouldn't be able to discover what other apps the user uses, nor what resource servers she accesses with those other apps
• a resource server, by default, shouldn't be able to discover what apps the user uses, other than those she uses to access that server, nor what other resource servers she accesses

Proposal

Note: acl:app is similar to acl:origin, only allowing finer-grained app identification (for example, with an OAuth2 redirect_uri), and allowing matching by prefix instead of exact match (so that acl:app "https://app.example/oauth/" matches an app-id of https://app.example/oauth/code). Other new terms in acl: used here are assumed for now to be obvious from context.

The resource owner/controller can specify one or more tag patterns in an acl:Authorization instead of an acl:origin or acl:app. Tag patterns can include wildcards (* and ? characters) and use traditional shell globbing rules to match. Example ACL:

# ACL for a container of chat messages, allowing
# read for all authenticated users who are using
# an app with a tag pattern that matches "Chat.Read" or "Photos.*".

@prefix acl: <http://www.w3.org/ns/auth/acl#> .

[]
    a acl:Authorization;
    acl:mode acl:Read;
    acl:agentClass acl:AuthenticatedAgent;
    acl:accessTo <./>;

    # apps the user has tagged "Chat.Read" or "Chat.*" or "*.Read" or
    # "*" will be allowed.
    acl:tag "Chat.Read";

    # alternatively, apps the user has tagged "Photos.Anything" or "Photos.*"
    # or "*" will also be allowed.
    acl:tag "Photos.*";

    acl:default <./> .

If any of the tag patterns that the user has assigned to the app that she's using matches any of the tag patterns in the acl:Authorization, then it's as if there was an acl:app match. Note that there is no global vocabulary of tags/scopes; tags are arbitrary, and what tags to assign to authorizations is entirely at the discretion of a resource owner. Tags SHOULD have the same meaning at least across resources in the same origin and realm.

The user associates tag patterns for the combination of an app, resource server origin, and security realm (the name of the protection space; that is, the realm authentication parameter of the WWW-Authenticate HTTP response header) in an App Authorization document. Tag patterns here can also include wildcards (* and ?) and use the same globbing as tags in ACLs. Here is an example App Authorization document assigning tag patterns Books.Read and Chat.* to app https://app.example/oauth/code when accessing server https://mike.example's realm /auth/:

# this is world-readable but has an unguessable URI like
#     <https://mike.example/wac/app-auth/b6d88441302c07700743b8d793ae2a8a.ttl#it>
# in a non-listable container.

@prefix acl: <http://www.w3.org/ns/auth/acl#> .

<#it>
    a acl:AppAuthorization;
    acl:resourceServer [
        acl:origin <https://mike.example>;
        acl:realm "/auth/"
    ];
    acl:app "https://app.example/oauth/code";
    acl:tag "Books.Read", "Chat.*" .

The URI for the App Authorization document MUST be in (at a sub-path of) an acl:appAuthorizations in the user's profile (otherwise the resource server MUST ignore it):

# this is the user's profile document
<#me> acl:appAuthorizations </wac/app-auth/> .

This container/directory SHOULD be configured to allow read of App Authorization documents by anyone and any origin; however, to protect the user's privacy (specifically, what apps the user uses and what resource servers the user accesses with those apps) including from other apps the user uses, listing the container's contents should be restricted to only the user, and then to only the user's trusted authorization management app.

The method by which an app discovers its App Authorization URIs is to be determined. I envision that each app will have an App Authorizations index file, generated and maintained by the user's trusted authorization management app, stored in a non-listable container, with a URI derived from the app's identifier, and readable only by the user and only when using that app, mapping between App Authorization URIs and resource servers, for example:

# App Authorizations index file for app "https://app.example/oauth/code".
@prefix acl: <http://www.w3.org/ns/auth/acl#> .

</wac/app-auth/b6d88441302c07700743b8d793ae2a8a.ttl#it>
    acl:resourceServer [ acl:origin <https://mike.example>; acl:realm "/auth/" ] .

</wac/app-auth/4f20846c1179e604048a589583dd6f9c.ttl#it>
    acl:resourceServer [ acl:origin <https://other.example>; acl:realm "Other Server" ] .

The non-listable container for App Authorization index files SHOULD return identical HTTP 403 responses both for accesses to non-existent index files and for accesses to existing index files which are not for the user∙app requesting it, so that an adversary (other user or other app) can't probe for index files to discover what apps the user might use.

The method by which the tag vocabulary being used by a server is communicated to the user or to the user's trusted authorization management app is to be determined. I envision that a method could integrate with the HTTP Privilege Request Protocol.

To associate tags with a Bearer access token, the app sets the app_authorizations key in the proof-token/POPToken to be the URI of the App Authorization appropriate for this server∙realm. The server verifies the App Authorization URI as being in one of the user's acl:appAuthorizations containers, and (re)loads/revalidates this document at least as often as the user's profile document. The server applies any tag patterns in this document that are for this server∙realm and the app being used, to match against tags in acl:Authorizations for which the user would otherwise be permitted.

[zenomt]

this is prototyped in my WebID Authorization Server for nginx.

[zenomt]

an acl:tag "*" in an acl:Authorization matches any app, regardless of any tags it might have for that server (including having no tags). in other words, every app effectively has an anonymous tag that a "*" can match.

an acl:tag "*" in an acl:AppAuthorization matches any tags (including no tag) in an acl:Authorization. in other words, every acl:Authorization effectively has an anonymous tag that a "*" can match.

the second case can be exploited to enable a coarse allow/disallow for an app at a server by either giving the app "*" or no tag.

[RubenVerborgh]

Good stuff, couple of quick points:

• Did we have a requirements engineering process, and if so, could you point to the outcomes of that process? They should provide us with a good checklist to see if this solution matches them.
• To what extent should the tags be IRIs such that they have universal meaning?

[zenomt]

• Did we have a requirements engineering process ...

no. this proposal is to address several points in several Issues (you can see three reverse references in the transcript above) both here and in other panels, as well as discussions on panel calls about problems with the current "trusted apps" scheme (and in particular how it doesn't solve the real problems of the user choosing what apps to use/trust, not the controller) and for attenuated app permission (although approaching that from the opposite direction).

• To what extent should the tags be IRIs such that they have universal meaning?

there is nothing stopping people from using IRIs as tags (except consideration for the characters * and ? with special meaning). i think trying to come up with a sufficient universal vocabulary of scopes/tags is a giant and hard project of its own.

my implementation stringifies tag objects before performing matching, so one could say (with a useful result)

<#acl3>  acl:tag  ex:Read, ex:Write .

the notion of arbitrary freeform tags and bidirectional wildcarding is borrowed from one aspect of AWS access control. applying wildcarding to IRIs is certainly possible, but you would want to design the vocabulary so that wildcarding could be applied effectively to achieve the user's intent. it might also start to get weird if (in some imagined vocabulary in use on some server) you wanted to express "Chat.*.Public" or something, but with meaningful IRIs.

[bblfish]

One can do this I think in a way that is more amenable to reasoning, and extension by using the wac:accessToClass and wac:agentClass relation combined with the flexibility of OWL descriptions. The advantage is that this would allow one to address many key use cases such as giving access to friend of friend as in this extract from my second year report

Below I consider how one can use that general framework for the use cases that the proposal attempts to address.

Let's take the use case of wanting to restrict write access to a set of images in write mode, to friends of one's friends using apps of a certain (set of) origins.

Describing the Agents

We want to take the intersection of a group of agents and a proof that they are using apps of a certain origin.

 <#AgentsWithTrustedOrigins> a owl:Class;
      owl:equivalentClass [ a owl:Restriction [
         owl:onProperty acl:origin;
         owl:allValuesFrom </apps/SafeOrigins#>;
      ]] .

<#FoafWithGoodApps> a owl:Class;
    owl:equivalentClass [ 
         owl:intersectionOf ( <#AgentsWithTrustedOrigins> <#TimFoaf> );
      ].

Of course for this to work we need to declare the acl:origin to have as domain foaf:Agent and one would need to verify the reasoning carefully.

Describing the Resources

We want to now describe a set of resources that match a certain pattern, for resources that have a pictorial representation. As mentioned in the Launcher App Proposal we need a way to find resources that match regular expressions. There we defined the acl:matching relation, which we could use here too,
but here to simplify I have acl:match and acl:matchStarting together define a class of resources.
(Which makes sense given that a regular expression mostly described collections of matching elements).

<#Realm>  a owl:Class;
      acl:matchStarting <.>;
      acl:match "**"  .

<#Pics> a owl:Class;
     owl:equivalentClass [ a owl:Restriction [
         owl:onProperty web:mime;
         owl:hasValue "image/*"; 
      ]] .

<#PicsUnderAuth> a owl:Class;
    owl:equivalentClass [ 
         owl:intersectionOf ( <#Pics> <#Realm> );
      ].

Perhaps one should think of web:mime as also defining a collection, in which case the above
could be simplified to mostly the third definition.

Putting it all together

 [] wac:accessToClass <#PicsUnderAuth>;
     wac:agentClass <#FoafWithGoodApps>;
     wac:mode wac:Write .

The wac:accessToClass is presently not supported, and the above gives some reasons to support it.

[elf-pavlik]

@bblfish it seems to me that you don't provide direct feedback on @zenomt's proposal but instead propose an alternative approach . I think it would work better to submit it in separate PR which would eliminate risk of 'hijacking' this issue and discussing all kinds of other approaches directly here. You could still later reference PR with your alternative approach in you comments on this proposal, but all the comments addressing your proposal would go in that dedicated PR.

---

The resource owner/controller can specify one or more tag patterns in an acl:Authorization instead of an acl:origin or acl:app. Tag patterns can include wildcards (* and ? characters) and use traditional shell globbing rules to match.

# apps the user has tagged "Chat.Read" or "Chat.*" or "*.Read" or
    # "*" will be allowed.
    acl:tag "Chat.Read";

I don't understand motivation for using those patterns, also does order in those pattern matter. Does "Read.Chat" differ from "Chat.Read" and would "Write.Chat.Read" match or not.

I'd like to clarify which requirements it tries to satisfy, very likely alternative approach can clarify the same requirements while reusing already defined constructs (eg. acl:Read) and don't require special patterns and characters.

The URI for the App Authorization document MUST be in (at a sub-path of) an acl:appAuthorizations in the user's profile (otherwise the resource server MUST ignore it)

IMO whenever we try to put any constraints on structure of IRI we should stay extra cautious. In this case a client (RS trying to enforce ACL) makes assumption about structure of IRI on the server (RS hosting user's app authorizations).

Again we should clarify which requirement it intends to satisfy. I think it relates to preventing any app to create authorization any authorization it wants for itself.

Note that there is no global vocabulary of tags/scopes; tags are arbitrary, and what tags to assign to authorizations is entirely at the discretion of a resource owner. Tags SHOULD have the same meaning at least across resources in the same origin and realm.

It sounds like this approach can't satisfy this success criteria from panel's README

An app can request access to a specific type of data without knowing the structure of resources on a Pod

With arbitrary tags, app can't request any specific authorizations. Related requirement also seems to appear in #31

[bblfish]

@elf-pavlik

@bblfish it seems to me that you don't provide direct feedback on @zenomt's proposal but instead propose an alternative approach .

Perhaps I have misunderstood @zenomt's proposal, but it seems that his main interest is to find ways to express in acls ways of limiting apps used by certain parties to a subset of resources on the server. I agree with that aim.

The sketch of an ontology he proposed is an illustration on how this could be implemented. As @zenomt asked for feedback, I presented a way to do this that would fit the current deployments, and allow it to further be extended to such central use cases such as allowing friends of ones friends access to a resource.

[zenomt]

@bblfish i think you misunderstood my proposal. the principle idea is that the resource controller should not specify the origins/app-ids that the user/requestor can use, but rather each user should be able to choose what apps to use (see the "Assumptions" section at the top) including apps the controller has never heard of. the solution is an indirection/normalization step where the resource controller classifies resources, and the user can map the apps she uses onto the different classifications. this separation also allows the user to change which apps she uses and modify the privileges each app she uses has without requiring the controller to modify any ACLs.

[zenomt]

@elf-pavlik

I don't understand motivation for using those patterns, also does order in those pattern matter. Does "Read.Chat" differ from "Chat.Read" and would "Write.Chat.Read" match or not.

order matters. the patterns are arbitrary -- i gave those as examples. they're compared like with Unix/Posix shell globbing rules, so a pattern "Chat.*" would match "Chat.Read" or "Chat.anything.whatever" or "Chat.*", but not "Chat" or "Foo". patterns could also be IRIs as @RubenVerborgh suggested above. the meaning of the patterns is opaque to the server; the only thing that matters to the server is whether they match.

I'd like to clarify which requirements it tries to satisfy

this is to try to solve the "trusted apps" problem and the "putting origins/app-ids directly in ACLs making it hard for users to choose what apps they want to use" problem, while protecting the user's privacy around what apps she uses and what servers she accesses.

edit sorry, the *s above turned into italics because i forgot to quote them properly. fixed.

[jaxoncreed]

I really like the idea of giving control of app authorization to the user rather than the resource owner.

Additionally, I like how tags essentially aren't treated as access control on the part of the resource owner. They're just ways to communicate the meaning of files so that users can apply their own access control.

2 questions:

• Is it okay that the resource server is responsible for enforcing the access control rules set by the user? It would be technically possible for the resource server to ignore the tag patterns the user has associated with the app they claim to use. Though, this might be all right because I cannot yet think of a reason a malicious RS would have to not respect the user's tag association as if an RS wanted to share extra data with a 3rd party it could just do it through back-channels without disrespecting tags.
• I share the sentiment with Elf when he says "With arbitrary tags, app can't request any specific authorizations." How would apps request specific authorizations when they haven't encountered a specific resource server before?

[zenomt]

@elf-pavlik

IMO whenever we try to put any constraints on structure of IRI we should stay extra cautious. In this case a client (RS trying to enforce ACL) makes assumption about structure of IRI on the server (RS hosting user's app authorizations).

agreed it's not ideal. however, in this case it's the user saying (with a claim in her webid) that this location(s) are containers and that a resource at a sub-path is permitted to make claims about authorizations she's given to an app. i couldn't think of another reasonable solution (regex? :P ) that can convey the necessary consent of the user while also preserving privacy.

@jaxoncreed

• Is it okay that the resource server is responsible for enforcing the access control rules set by the user?

the resource server is ultimately responsible for enforcing all access control (see bullet 2 in my assumptions). a resource server might not enforce or honor the user's preferences no matter what scheme is used. this proposal is for a method that can solve this problem for the user's own trusted resource server(s), and can optionally (by server configuration or ACL configuration) extend that to visitors as well.

• How would apps request specific authorizations when they haven't encountered a specific resource server before?

this is an open area of research (see the second-to-last paragraph in the proposal) that i don't have a general solution for yet. perhaps this can happen via extensions to the privilege request protocol, or by messages sent to the user's inbox, or by out-of-band. i think initially it'll be your own resource server and your own tags (so you'll know them, and configure your app(s) by hand or with a permission management app), and for most cases it'll be "i care about what apps i use, but i don't care about what apps you use".

[RubenVerborgh]

Thanks @zenomt for answering my two points.

I see a a requirements document as a necessity for evaluating solutions, so we should probably track that in another issue. This is more a point of criticism for this repo than it is for this specific issue; we simply cannot pick solutions without knowing exactly what they solve.

Besides that, I'm not a big fan of tags as proposed here. Sentences like Tags SHOULD have the same meaning at least across resources in the same origin and realm. make me worry that they are a poor man's substitute for URLs. Note that a sufficient universal vocabulary of scopes/tags is not a precondition to using URLs.