Client identification

[csarven]

Clients making HTTP requests on behalf of agents (social entities) may need to be given different set of access privileges than the agents.

Considerations:

• Client is authenticated - protocol agnostic.
• Specific predicate for the client (eg. acl:client as possibly a subPropertyOf acl:agent) vs. reuse acl:agent since the object ie. the WebID that's changing.
• Access privileges given to a client is same as agent's or can be different.
• Related but may not be relevant: whether an access subject (eg. agent, agentGroup, agentClass) delegates (acl:delegates) a client to act on behalf of the agent.

[timbl]

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.

[timbl]

("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)

[elf-pavlik]

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. https://solid.github.io/authorization-panel/authorization-ucr/#uc-client-constraints

[TallTed]

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

[matthieubosquet]

Specific predicate for the client (eg. acl:client as possibly a subPropertyOf acl:agent) vs. reuse acl:agent since the object ie. the WebID that's changing.

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 x using a client y. The WAC engine will need to be able to discriminate between the two since I assume the aim here will be to further restrict access depending on which client an agent uses, that is, if agent x has read/write/control and the client y they're using has only read, then read should be the only granted permission.

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?

[elf-pavlik]

A server will receive a request performed by an agent x using a client y.

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:

Resource Client (RC, aka "client")

Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf.

Requesting Party (RQ, aka "user")

Operates and interacts with the RC.

---

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 would like to emphasize that UC linked above has title 2.5.2. Limiting application access while not acting as resource controller.

[acoburn]

The GNAP terminology is very useful here, even if one is not using the GNAP protocol.

I am :+1: on any mechanism that is able to distinguish between an App (i.e. "Resource Client") and a User (i.e. "Requesting Party")

[matthieubosquet]

I would like to emphasize that UC linked above has title 2.5.2. Limiting application access while not acting as resource controller.

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.

[elf-pavlik]

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.

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.

[jeff-zucker]

The term "client" has multiple possible meanings. What makes sense to me is sub properties of acl:agent:

  acl:user [a foaf:Agent, foaf:Person]
  acl:app [a foaf:Agent, dc:Software; rdfs:comment "an OIDC Resource Client"]
  acl:group [a foaf:Agent, vcard:Group] 

[elf-pavlik]

client is pretty established in OAuth2 and GNAP which aims to learn from OAuth2 experience.

[jeff-zucker]

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.

[elf-pavlik]

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.

• Social Agent can act as End-user or Resource Owner
• Application pretty much acts as a Client.

[AJamesPhillips]

@jeff-zucker your comment: https://github.com/solid/web-access-control-spec/issues/81#issuecomment-917212377 reminds me of hueniverse 's insightful and ardent critique of OAuth2: https://web.archive.org/web/20160304014802/http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ https://web.archive.org/web/20160306192304/http://hueniverse.com/2012/07/30/on-leaving-oauth/ https://vimeo.com/52882780 https://web.archive.org/web/20160304014608/http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-an-oauth-replacement/

[woutermont]

@csarven, do you now what the current status is of client-id in WAC, and how we can make this gain some progress?

[tomhgmns]

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?

[csarven]

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:

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 acl:client rdfs:subPropertyOf acl:agent may be incorrect based on the rdfs:comment - contrary to my first comment - but would be allowed with respect to the rdfs:range value. As far as I know (read: anecdotal evidence) "agent" wasn't particularly limited to person/social entities but I'm not going to argue that here. We can however consider whether the definition of acl:agent needs to be improved, e.g., along the lines of the term "agent" (not to be conflated with acl:agent) that's currently used in the WAC spec:

<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 acl:agent's comment with that definition may suffice (without introducing a new property acl:client) with respect to allowing Authorizations to take client identifier into account because #authorization-evaluation is generally about finding a matching graph, as demonstrated with ASK queries in the spec. So possible to have different Authorization graphs for a person and a client all meanwhile using acl:agent for both - if we broaden the definition of acl:agent. But let's come back to this.)

I would add that in the case of only using acl:agent, while each thing (person, social entity, or software) can describe itself, that information needs to be either repeated in the #acl-resource or one will have to dereference the URI. However, with acl:client, it is not necessary to look for additional information about the the thing.

---

Let's work through perhaps some obvious questions / assumptions. Using acl:client (or acl:agent) for the purpose of discussion:

• Current #authorization-evaluation does not observe client identifiers so any client would be granted access. This is not to be conflated with what's intended or constrained with acl:origin!
• Does acl:client denote a URI that identifies a client?
• What would #authorization-conformance be when acl:client (and related properties) is introduced?
• How would #authorization-evaluation be when there is no Authorization with acl:client?
• Are notions acl:clientGroup, acl:clientClass (similar to acl:agentGroup, acl:agentClass) necessary? At this time?
• How should #authorization-evaluation be when both acl:client and acl:origin are present? or acl:client but without acl:agent?
• Would #loss-of-control-mitigation be effected if acl:client is introduced, e.g., is it assumed that the storage owner can use any client?
• ...

[RubenVerborgh]

Since WAC was mentioned above, we probably also want to clarify that this is an orthogonal problem. One of the mentioned benefits of ACP was better client identification (or rather that WAC did so in an insufficient way), but this is a problem of authentication that IMHO should be solved orthogonally from the problem of authorization.

[bblfish]

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]

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 being a secure app it's signing of a header is no different than a browser using an X509 client certificate.

"Sig being like X509" and "thought as coming directly from the user" are two different things; and at least the latter seems incorrect. It's not because I have signed in (with a client certificate or otherwise) that suddenly every single request made by the app is approved by me.

In any case, let's not have that discussion here; this issue is about how to identify clients. If we want to start a separate issue to question the need of identifying clients, we can do so.

[bblfish]

@RubenVerborgh regarding identifying an app: you can identify an app with a WebId as I did in the WAC rules above. There </apps/bankApp/Id#> is meant to be the App Instance WebID. As the Wallet (Launcher App) launches the Banking App, it knows that the process it is communicating with is that app and by consulting its WAC rules the Wallet can decide when to sign the request headers.

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

[woutermont]

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

[RubenVerborgh]

(Makes sense, probably want to make the title of the issue more precise.)

[woutermont]

☝️ @csarven @elf-pavlik @justinwb I've given it a shot to implement my interpretation of this in the CSS

[rosshorne]

Hi all, I'm bumping this, since I think it wasn't resolved and is critical, as mentioned here: https://github.com/solid/solid-oidc/issues/221

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.

[woutermont]

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 (https://github.com/CommunitySolidServer/CommunitySolidServer/pull/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.

[rosshorne]

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: The point made by @woutermont about the usage of WAC/ACP, e.g., public v.s. private access control, I can see multiple sides to. In some settings, it's better to assume the app knows the access control rules it should follow (perhaps because the pod follows a known policy in order for it to be used with a particular trusted app), so that a trusted app can connect to a pod without leaking unnecessary information about what the pod may be used for to attackers. In other scenarios, its better to make the access control rules public so that apps can follow their nose more so (I understand that this is currently how most implementations work, and is what @woutermont points to -- please correct me if you were pointing elsewhere @woutermont). However, this kind of problem may be addressed separately from the priority problem: that is, can we agree on dropping WAC to avoid data breaches due to WAC missing essential information provided by the ACP context graph.

[woutermont]

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. https://github.com/solid/specification/issues/447, https://github.com/solid/authorization-panel/issues/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 https://github.com/solid/specification/issues/447.

[bblfish]

I wrote up in detail how clients can be Authorized using Web Access Control here. https://github.com/co-operating-systems/PhD/blob/main/UseCases/ClientAuth.md

Would be very happy for feedback. (updated ClientAuth.md at 13:39 CET)