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

On 2025-04-22 22:44, elf Pavlik wrote:
> 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.

What this line of discussion translates to is that the autonomy of the 
application user, presumably the one who manipulates data in a storage, 
is constrained by the amount of control that a storage owner exerts.

And on a related note, even the storage owner is ultimately limited by 
the constraints that the URI owner sets on the whole storage (as per Web 
architecture) meanwhile minding the fact that the exact relationship 
between the URI owner and the storage owner is deliberately not 
described ( 
https://solidproject.org/ED/protocol#storage-owner-uri-ownership ).

So, this is more about an acknowledgement where the constraints are as 
opposed to making a qualitative judgement.

As I understand it, some sort of a client registration is needed in 
Solid-OIDC but there is no particular requirement for either dynamic or 
static registration. Both dynamic and static client registrations have 
their limitations.

> 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


What begs the question is whether Solid-OIDC, to reach its full 
potential, requires another specification like SAI or others. This also 
raises the complexity of that particular branch of solutions, in 
addition to the overall complexity in the ecosystem where Solid-OIDC 
might be either inapplicable or inadequate. And that's all in addition 
to the number of protocol interactions and user involvement that's 
expected in Solid-OIDC. As I understand it, there are too many points of 
failures in this picture.

The concerns about which applications should have the rights to 
manipulate certain data (authorization) are valid, but they are also 
orthogonal to the scalable authentication model with affordances for 
good UX.

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

As I understand it, Solid-OIDC's static client registration is not well 
suited for a (highly?) decentralised ecosystem like Solid envisions.

In the context of web browser extensions, static client registration 
appears to be impractical. And <browser>-extension: URI scheme is not a 
valid client_id. Only URIs that are shipped from a third-party 
controlled application "store" would be permitted. Every extension 
install can't realistically be pre-registered with every IDP of course, 
and allowed redirects are naturally fall short on the open web. However, 
dynamic registration works in this context.

Limiting applications to specific IDPs raises concerns about actual user 
(or individual) autonomy. It seems more like enabling affordances for 
more centralization rather than decentralization. Along with this comes 
concerns about user privacy, but one's mileage may vary.

While Solid-OIDC is useful in some scenarios, it is important to 
acknowledge its limitations for Solid, and I hope we can move the 
discussions toward alternative authentication mechanisms that can cover 
other use cases and support better UX.

-Sarven
https://csarven.ca/#i