Re: Usability and scalability of Solid-OIDC in a decentralized ecosystem

On 2025-04-22 13:51, Virginia Balseiro wrote:
>> Besides that dynamic identifiers are practically useless when
>> setting a
>> client restrictions using for example `acp:client` matchers.
>  If operators can set client restrictions on certain operations and/or
> resources, then the user is not free to use whatever app they prefer
> or trust. Doesn't this break the whole 'user autonomy' concept?

I'm not sure what do you mean by 'operators'. If you refer to storage 
owner restricting which apps can be used to access some of the resources 
in **their** storage, even if another end user who they shared access 
with is the one who accesses the resource. I think it is 'unfriendly' 
practice, but storage owners have ability to set such restrictions, they 
own the data in **their** storage.
Personally I'm working on access delegation in SAI, so that the end user 
can authorize what applications they use can do on their behalf, across 
data owned by any number of data owners.
Relevant references:

* https://github.com/solid/specification/issues/517
* https://github.com/solid/specification/issues/650


>> Do you seen the issues you mention still applicable when Client IDs
>> which dereference to Client ID Documents are used?
>  If the client need to make themselves aware / known to the IDP via a
> manual registration process in some sort of registration or broker
> service to obtain certain credentials, then yes.

No, use of Client ID that dereferences to Client ID Document doesn't 
require any manual registration step.
Over a year ago I made this example using penny that shows `acp:client` 
matcher.

* https://gitlab.com/elf-pavlik/css-nickel-dime

Penny required one line change to use Client ID Document on localhost

* 
https://gitlab.com/elf-pavlik/css-nickel-dime/-/commit/41b1226390e2cfff412c28109db875390c98523f?page=2#720b615d99728d29515c1d69e416d5eb6dd20c07_39_39


> 
> Just to be perfectly clear, I'm not questioning the security aspects
> so please abstain from security reassurances :) I'm sure it is secure,
> I am wondering how it fits into the selling points of Solid of using
> your preferred identity and applications, etc. I'm just wondering how
> it can scale if clients need to cater to specific IDPs.

Clients don't need to cater to specific IDPs. In most cases user chooses 
their IdP. In some contexts this may differ and something like 
`acp:issuer` may restrict which IdP has to be used.
While WAC doesn't allow restricting app access except very specific 
intranet deployments, Michiel demonstrated a way where resource owner 
can restrict apps when they also act as end user

* https://youtu.be/5Q1nUmGdaXE

Since it is limited to what I would call 'self-confinement', and doesn't 
allow other end users, who resource owner shared access with to restrict 
access of apps they use. I'm focusing on access delegation based on SAI 
Data Grants which will satisfy those requirements.

* 
https://solid.github.io/authorization-panel/authorization-ucr/#uc-client-constraints

I'm have big part of it already implemented in https://sai.js.org and 
now I start writing custom authorizer for CSS. It will use SAI Data 
Grants with delegation chains directly so it will be an alternative to 
both WAC and ACP.
In last months I have been coordinating with https://activitypods.org/ 
team and they are working on second independent SAI implementation.
We are also discussing a test suite which would test conformance of both 
implementations.

Received on Tuesday, 22 April 2025 20:44:34 UTC