Proposal: scope tags in WAC for fine-grain user control of app privilege about authorization-panel HOT 22 CLOSED

To @RubenVerborgh's point about a requirements document and being able to evaluate solutions, I would want to make sure that any of the suggestions promoted by this panel consider caching strategies. Because the WAC lookup algorithm is relatively expensive, computationally, it is really important that proposals lend themselves well to cache implementations: what might an in-memory cache look like? what might a distributed cache look like?

from authorization-panel.

this is prototyped in my WebID Authorization Server for nginx.

from authorization-panel.

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.

from authorization-panel.

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?

from authorization-panel.

• 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.

from authorization-panel.

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.

from authorization-panel.

@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

from authorization-panel.

@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.

from authorization-panel.

@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.

from authorization-panel.

@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.

from authorization-panel.

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?

from authorization-panel.

@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".

from authorization-panel.

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.

from authorization-panel.

Besides that, I'm not a big fan of tags as proposed here. ... make me worry that they are a poor man's substitute for URLs.

i think tags being URIs is a good idea (which should be RECOMMENDED), but it shouldn't be required. as i mentioned earlier, the idea of tags being opaque arbitrary strings with wildcarding is borrowed from Amazon Web Services access control, and the examples i've listed above should seem comfortably reminiscent of OAuth2 scopes.

certainly any default out-of-the-box tag vocabularies in a Pod/permission management system should use URIs, but there's no reason to constrain this scheme to only URIs.

from authorization-panel.

the idea of tags being opaque arbitrary strings with wildcarding is borrowed from Amazon Web Services access control, and the examples i've listed above should seem comfortably reminiscent of OAuth2 scopes.

It's important to mention that with Solid, we're building systems with a desired level of interoperability beyond what has ever been created before. So the existence of a certain technique is by itself not necessarily a good indicator for fitness for Solid.

For instance, Amazon Web Services also use usernames (or e-mail addresses), but we're not arguing that WebIDs could be usernames instead of URLs.

from authorization-panel.

@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.

If the aim of the proposal is to limit which apps should be used for which types of resources, and that this should be specified by the client -- as indeed the trusted apps section of the WAC spec indicates -- then this could perhaps best be done by the Launcher App. The Launcher App could write down for each App a set of constraints on where the App can authenticate to edit data using something similar to the ontology I described above, and then only give tokens to apps for resources that fit that restriction. It seems to me like the Launcher App would be better able to enforce such restrictions than the resource server, thereby leaving the resource server the job of more coarse grained restrictions. (Even though as I showed the resource server could follow some such rules too).

It may be that for some use cases it would be helpful for resources to publish metadata about the type of data they contain that goes beyond mime types, so that the Launcher App could use is rules that limit an App to writing files with certain kind of data. Eg: the calendar App could be restricted to only calendar type data, and enforce that by looking at the metadata of the resources.
(This would be even easier if the Launcher App could completely control the fetching of resources, but I am not sure how far that is possible. Going even further the Launcher App could control all data access and store data in a quad store with published acl rules, thereby allowing (and restricting) apps to access data via a query interface...).

from authorization-panel.

followups from today's panel meeting:

@jaxoncreed mentioned (as i understood him) a treatment of users and apps in a similar manner, which sounded to me a lot like Attribute Based Access Control (ABAC). i believe ABAC would be a substantial change to the semantics of today's WAC, and deserves its own issue and research independent of this proposal.

i think related to this was the idea of having a permission/mode mask in the AppAuthorization, to limit what access modes an app could exercise at a server. i wasn't clear on how fine-grained that should be, but if combined with tags, origin-wide enable/disable of acl:Read, acl:Write, acl:Append, and acl:Control is probably both sufficient and understandable by ordinary users. as i mentioned in the meeting though, there must be an incentive for an app to communicate any limitations like that (if the way a server learns the AppAuthorizations works like i described above), which means the default must be no permission at all. this has a chicken-and-egg problem where the app doesn't have the necessary permission to find its AppAuthorization URIs. workarounds could include "you always have read" or "acl:origin "*" or explicit origin/app in an ACL ignores the mask". both of those are weird and untidy and, importantly, workarounds, which means it's not the right design. i think that if tags are used properly, a coarse permission mask wouldn't be needed (also see the next paragraph).

while considering the above, though, i thought it might be desirable to have a "default" AppAuthorization for an app (which could be created on initial app permission setup or something) that could have an acl:origin "*" in the acl:resourceServer, and which an app could use if it didn't have a specific App Authorization document for a server. this might especially be interesting where tags are URIs and there was a chance of a universal-ish vocabulary. for safety, a server should ignore any wildcard app tags for the default * origin, and a well-behaved permission management app shouldn't let the user assign them for the default origin.

speaking of universal-ish tag vocabularies and the user's cognitive load (@dmitrizagidulin), i had envisioned that a practical Pod for ordinary users would come pre-configured with containers for common stuff (like Photos, Chats, Documents, Whatevers), with reasonable default ACLs (that could include reasonable classifications via reasonable tag vocabularies), and come with a reasonable default permission control app that could come pre-configured with a curated set of useful tags to easily apply to new resources/collections as well as to new apps.

from authorization-panel.

@jaxoncreed for permission masks: what if the user's application tags were only for specific access modes, so you could say "this app has chat:Public but only for acl:Read". if a resource was tagged for chat:Public for read and write, this app would would only be able to read even if the user had read and write. an App Authorization could look something like

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

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

    # this predicate needs a better name
    acl:tagMode [
        acl:mode acl:Read;
        acl:tag chat:Public
    ] .

and of course an acl:tagMode (better predicate name needed) could list multiple acl:modes and multiple acl:tags, and an acl:appAuthorization could have multiple acl:tagModes.

also, i implemented support for a default acl:origin "*" App Authorization in my auth server because i think that's a good idea. i think a default App Authorization with permission/mode masks could be very interesting.

note that the owner/controller is free to assign different tags for different access modes too, giving lots of flexibility.

edit: i implemented acl:tagMode in my auth server.

from authorization-panel.

@zenomt If I understand this correctly I think this could work. To confirm, the resource owner would be able to use acl:tagMode functionality as well, correct?

from authorization-panel.

@jaxoncreed the resource owner would just use acl:tag, but she could put different ones in different acl:Authorizations to associate different tags with different permission modes (and other combinations of users/groups, resource classes, etc).

edit: in other words, acl:tagMode isn't necessary for the resource owner (server side) because acl:tags are already associated with, and only apply to, the acl:modes in the acl:Authorizations.

from authorization-panel.

since opening PR #62, i propose closing this issue as redundant and outdated.

from authorization-panel.

Sounds good

from authorization-panel.