Client identification

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.

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

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

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?

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.

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

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.

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]

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

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.

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

@jeff-zucker

@jeff-zucker your comment: #81 (comment) 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/

@RubenVerborgh

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

@RubenVerborgh

@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

☝️ @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:
solid/solid-oidc#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.

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.

@woutermont

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.

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

Notwithstanding the proposals made by Wouter and Henry, I would like to mention another option for how we could resolve this issue:

Currently, acl:origin is not intended to identify clients. But we could repurpose it. If we change the spec to say that when WAC is combined with Solid-OIDC, the azp claim as defined in https://solidproject.org/TR/oidc#tokens-id should be matched against any acl:origin restrictions of an Authorization, then this would (I think) create a safe chain of trust from the resource owner to the consent dialog to the IDP to the resource's owner's browser, to the origin of the server (azp) receiving the OIDC redirect.

This would still make WAC hard to use due to basic permission vs basic denial, since an Authorization which has no acl:origin triples would mean 'any client', but we could mitigate this with a second spec change so that if the agent is specified but the client is not, then instead of interpreting that as 'any client', we would interpret that as 'no client' (maybe with the exception of clients that sit on the origin of the storage and/or the origin of the authenticated agent's WebID and/or the origin of the agent's IDP/issuer).

If a server does authorization with WAC and only allows authentication with WebID+TLS (not with Solid-OIDC) then I think #34 would not apply and acl:origin would be enough to identify clients, since the client-side cert would stay in the browser and not be shared with a proxy.

Not sure if I'm right about this, and it's not how WAC is currently used in Solid. Also, it would only work if every single authorization that mentions a given agent also contains at least one acl:origin triple to constrain it, so it would be very hard to use, but still... 🤯

I'd like to add my two cents on the questions raised at the end of this call to action:

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!

I think I agree. acl:origin is already understood to refer to CORS. Re-using this term could be misleading.

Does acl:client denote a URI that identifies a client?

I would suggest so - and even specify that this URI is a dereferencable client_id.
On the other hand, saying "something that is a client", would allow to use a blank node and then define other things in there - but I would consider such things "loose ends" in a specification. And I do not like that too much.

What would #authorization-conformance be when acl:client (and related properties) is introduced?

Similar to acl:agent. Either acl:client or acl:clientClass (to declare that the resource is accessible by any / public clients) must be present

How would #authorization-evaluation be when there is no Authorization with acl:client?

Similar to acl:agent. Everything is forbidden if not explicitly allowed. Inheritance of ACLs is fine for me.

Are notions acl:clientGroup, acl:clientClass (similar to acl:agentGroup, acl:agentClass) necessary? At this time?

acl:clientClass is necessary to state that a resource should be accessible by any client / public clients (i.e. the ones without a dereferencable client_id)
acl:clientGroup feels the same as acl:agentGroup, which - for me - is just a level of indirection to work around access delegations (define rules per mode with distinct user groups, and give access to modify the groups to other agents).

How should #authorization-evaluation be when both acl:client and acl:origin are present?

In my opinion, acl:origin is unfit as a security control. From a formal standpoint, it does not provide any security guarantees.

or acl:client but without acl:agent?

acl:agent, acl:agentGroup or acl:agentClass must be present (#authorization-conformance), so this is a non-issue.
If acl:agent or sorts are not set, the rule is not to be applied.

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?

No - and it should not be assumed that an owner (btw, dont like that term - it has no grounding) can do everything on their Pod. In-fact, in highly regulated industries an "owner" may just have read rights and control read rights but not write. And this is fine. I do not like that "owner" requirement at all.

No - and it should not be assumed that an owner (btw, dont like that term - it has no grounding) can do everything on their Pod. In-fact, in highly regulated industries an "owner" may just have read rights and control read rights but not write. And this is fine. I do not like that "owner" requirement at all.

Owner has been created to unlock .ACL either malformed or with no control access

agent: Owner
client: Owner's authorization agent

could be the equivalent once no client has access by default

Navigation Menu

Repository navigation

Client identification #81

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Client identification #81

Description

Activity

timbl commented on Jun 15, 2021

timbl commented on Jun 15, 2021

elf-pavlik commented on Jun 15, 2021

TallTed commented on Jun 16, 2021

matthieubosquet commented on Jun 29, 2021

elf-pavlik commented on Jun 29, 2021

acoburn commented on Jun 29, 2021

matthieubosquet commented on Jun 29, 2021

elf-pavlik commented on Jun 29, 2021

jeff-zucker commented on Sep 10, 2021

elf-pavlik commented on Sep 10, 2021

jeff-zucker commented on Sep 10, 2021

elf-pavlik commented on Sep 11, 2021

AJamesPhillips commented on Sep 13, 2021

5 remaining items

bblfish commented on Nov 8, 2022

woutermont commented on Nov 8, 2022

woutermont commented on Dec 13, 2022

rosshorne commented on Aug 9, 2023

woutermont commented on Aug 9, 2023

rosshorne commented on Aug 10, 2023

woutermont commented on Aug 10, 2023

bblfish commented on Aug 10, 2023

michielbdejong commented on Jan 16, 2025

michielbdejong commented on Jan 23, 2025

uvdsl commented on Jun 23, 2025

bourgeoa commented on Jun 23, 2025

elf-pavlik commented on Jun 23, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions