Client identification #81
Comments
|
When a person with one webid does something using an authenticated client app, then they both need to have access. Both in this case have a webid. Seems logical to use acl:agent to connect to both. |
|
("delegation"? No, when you are talking about a bot, a free running system with its own webid, not an app, then delegation is when I say that I want to confer some rights which I have to the bot, say, or another person) |
|
I believe this use case may help with illustrating case where user delegates subset of their access rights to an application they use to exercise their access rights, while following the principle of least privilege. |
|
"Clients" appear to be, and should likely be referred to as, "agents (software)" or "software agents" when used alongside or with "agents (social entities)" or "social agents" (which appear to be "users", which are commonly discussed alongside "clients" and "servers"). This will likely help to simplify some things (though it may complicate others) when you get deeply into delegation and such, as I would think there's less "special" handling needed for a "delegate client" (which is a new class that largely duplicates agent) than for a "delegate agent" (which is a slightly specialized case of the agent class). |
I don't think the same predicate can be used for identifying agent and client in a WAC Authorization. A server will receive a request performed by an agent Is my assumption correct? Maybe it is worth considering that it might imply a significant departure from WAC's current "grant permission" on first match approach. Maybe I'm naively thinking the client would be defined alongside agents in an Authorization and actually what is meant here would be a completely separate mechanism for filtering access permissions altogether. I'd be curious to understand what would be envisaged if that were the case, maybe an AuthorizationFilter? |
That's the assumption in Solid-OIDC, Resource Server (Solid Storage) should have both identifiers available for any request. The only exception is access by navigating the web browser directly to the resource, in which case the Solid Storage itself acts as OAuth client. Grant Negotiation and Authorization Protocol: 1.1. Roles uses following terminology:
I would like to emphasize that UC linked above has title 2.5.2. Limiting application access while not acting as resource controller. |
|
The GNAP terminology is very useful here, even if one is not using the GNAP protocol. I am 👍 on any mechanism that is able to distinguish between an App (i.e. "Resource Client") and a User (i.e. "Requesting Party") |
I also think it would be useful and make sense to be able to filter resource access permissions based on Resource Client globally. The natural fit for expressing such restrictions in my opinion would be the WebID. But then, that is a completely new mechanism, so I wouldn't jump on it. Additionally, I think it will be quite prevalent to restrict resource access permissions based on Resource Client for specific resources over which one is acting as the resource controller. Almost no app should be unrestricted to access my data and I'd be keen to see what such access permissions filters might look like too. |
Do you refer to https://github.com/solid/web-access-control-spec#other-ideas-about-specifying-trusted-apps ? This approach has some privacy issues, person may no want to make public what authorization they give to which app. We have prior conversation on alternative approaches. One would involve out of band notification to relevant parties where app access restrictions have to be enforced. Another alternative would just require client application to present claim (credential / capability) proving authorization that user granted it. I believe this conversation should continue elsewhere, just hinting here that we have prior discussions around those requirements. |
|
The term "client" has multiple possible meanings. What makes sense to me is sub properties of acl:agent: |
|
And how many people who aren't familiar with those standards are going to know or remember the difference? Am I the agent or the client? And in this case, the client is an agent which adds an additional confusion. |
|
In Interop spec we refer to Person or Organization as Social Agent and to clients as Applications. I think we should still map them to GNAP / OAuth2 terminology.
|
|
@csarven, do you now what the current status is of client-id in WAC, and how we can make this gain some progress? |
|
As we are implementing Solid Interop, we are running into the issue that there is no way to define by which application a social agent may do something with data. In other words, this issue becomes very relevant... @csarven can we bring this issue to the surface again by discussing it during a weekly community meeting? |
|
Noted re surfacing. To help with the spec progress, as always, commitment to implement or adequate implementation experience works. I gather that's been the case here and elsewhere for some time now. Edit: clarified the current definition. The current definition of acl:agent
a rdf:Property ;
rdfs:label "agent" ;
rdfs:comment "A person or social entity to being given the right" ;
rdfs:domain ac:Authorization ;
rdfs:range foaf:Agent .Something like <https://solidproject.org/TR/2021/wac-20210711#agent>
a skos:definition "An agent is a person, social entity or software identified by a URI, e.g., a WebID denotes an agent [WEBID]."@en .Updating I would add that in the case of only using Let's work through perhaps some obvious questions / assumptions. Using
|
|
Note, with HTTP Sig working via a wallet or through an http proxy, the signatures can be thought of as coming I think directly from the user. Ie. the Solid Wallet (see now an nlnet project), being as it is a secure app, its signing of a header is no different than a browser using an X509 client certificate. In BAN Logic this would come down to the relation that the wallet speaksFor the user. Ie. Everything the Wallet says the User says too. In the wallet setup, there is no need to limit clients in WAC rules. Instead, the wallet limits what it signs instead. The Wallet could itself have WAC rules as to what spaces a client can access. Just thinking about this quickly, here is an idea of the rules the Wallet could use to limit the banking app to Wells Fargo's web site. <#bankAppRule> a wac:Authorization;
wac:agent </apps/bankApp/Id#> ;
wac:accessToClass [ allResourcesStartingWith <https://wellsfargo.com/> ]
wac:mode wac:Read, wac:Write . |
|
@RubenVerborgh regarding identifying an app: you can identify an app with a WebId as I did in the WAC rules above. There On the "speaks for" relation see Abadi's Logic in Access Control tutorial notes from 2003. The speaks-for relation was initially developed as early as 1989 by Abadi, Needham and Mike Burrows in a famous paper. (Note Burrows was the author of the AltaVista search engine). (You can have the wallet sign every request btw, in which case it is approved by you, assuming your setup is correct of course)... |
|
@RubenVerborgh, I did not interpret this issue as being about identification of the client (Solid-OIDC already handles that). Rather, the question here i.m.o. is what happens after a client is authenticated: how can a system using WAC incorporate that identity information in access control rules? |
|
☝️ @csarven @elf-pavlik @justinwb I've given it a shot to implement my interpretation of this in the CSS |
|
Hi all, I'm bumping this, since I think it wasn't resolved and is critical, as mentioned here: Would it make sense to resolve this thread as an editorial decision in the Solid Protocol Spec itself? Specifically, references to WAC should be dropped entirely from the Solid Protocol spec and ACP made normative. The property acp:client in the context graph is essential. Naming the client in ACP ensures that users (acp:agent) can use the same identity to log in to multiple apps (acp:client), without information intended for one app being compromised by another app. Not all apps can be trusted to the same degree. The thread already reflects well this problem, but I didn't see action in the Solid Protocol spec. Officially removing WAC and making only ACP normative I see as the simplest solution. This has the added benefit of simplifying the Solid Protocol. |
|
While there hasn't been any engagement on WAC lately, it is reasonable that an update to the spec can resolve this. I did a prototype implementation of such a possible update in the CSS (CommunitySolidServer/CommunitySolidServer#1537). That being said, both WAC and ACP are not fit as access control mechanisms by themselves. Direct access to access control resources should be avoided. The use of WAC/ACP should be an implementation decision of authorization servers, rather than of resource servers. Solid protocol should i.m.o. include neither, and fully separate access control from resource management. |
|
I see the update @woutermont links to above suggests extending WAC to address the problem. That's fine technically, but it just means that WAC converges more with ACP (as noted already in the comments in CSS). It would be cleaner to pick one or the other instead of having two convergent specs, and since WAC must evolve to cope with security, then ACP is a cleaner basis. It would be interesting to know if there are security arguments for evolving WAC v.s. dropping WAC and making only ACP normative. Whether the status of WAC should be clarified in the Solid Protocol specification or whether references to WAC and ACP should be removed from there and clarified elsewhere, as @woutermont suggests, is an editorial decision. I don't have an opinion on where in the specification this edit should be made. The editors might have a view. However, it is a priority issue to resolve in one way or another, since the current spec permits data breaches by exploiting WAC or misusing ACP (think about all the fines being issued these days). The action point here is: what editorial decision should be made regarding WAC. Separately: |
|
WAC will never fully align with ACP, since they are based on different views of security (basic permission vs basic denial). There has been a lot of words on this already (e.g. solid/specification#447, solid/authorization-panel#128). Advocates of either of them will likely never be persuaded to drop one in favor of the other. One way to go forward with both of them could be merge them together into a specification that would enable the basis (permissoin or denial) to be set freely somehow, though I am not really interested in exploring that personally. Re public access control rules, it is just basic separation of concerns that authorization is managed by a different entity than resource management. No use case comes to mind that would benefit from that, which would not benefit equally or more from separated non-public management of access control rules by an authorization server (which can of course be hosted by the same provider as the resource server). That being said, this issue is actually specifically about the absence of client identification in WAC. It might be better to raise your WAC-vs-ACP concern in a new, separate issue, or continue in solid/specification#447. |
|
I wrote up in detail how clients can be Authorized using Web Access Control here. Would be very happy for feedback. |
Clients making HTTP requests on behalf of agents (social entities) may need to be given different set of access privileges than the agents.
Considerations:
acl:clientas possibly a subPropertyOfacl:agent) vs. reuseacl:agentsince the object ie. the WebID that's changing.acl:delegates) a client to act on behalf of the agent.The text was updated successfully, but these errors were encountered: