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

On 2025-04-28 05:03, Sarven Capadisli wrote:
> 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.
> 

I'm not sure if any of the above is specific to Solid-OIDC. If we try to 
think of any other possible mechanism to authenticate identity of the 
client/application. Wouldn't above still be applicable?

I think End User would need to obfuscate identity of the client to 
change the dynamic. So for example End User would use applications which 
don't directly connect to the Resource Server but send messages through 
another server controlled by the End User.

Haven you looked at this work? https://ceur-ws.org/Vol-3759/paper10.pdf

I would still love to ask Christoph if we could have a meeting, possibly 
a special topic one, where they could dive with us into more details.


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

Solid-OIDC doesn't really specify how static registration can be used. I 
believe it also doesn't require that OP supports dynamic registration.

Once again, Client ID Documents seem to be the most reliable ones and 
they don't require any registrations. There is also this draft that 
cites Solid-OIDC work:

https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/

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

I think you answered your own question to the extent. By design 
Solid-OIDC wasn't addressing AuthZ, so if we want to take it into 
account we need something else. At the same time, if SAI Data Grants are 
pushed in the same way as Solid-OIDC ID Token, for example via UMA 
claims pushing. The ID Token becomes redundant.

IMO we shoot ourselves in the foot by trying to separate AuthN and AuthZ 
to hard. In the end we want to satisfy requirements of AuthZ, if access 
policies are based on specific identities then AuthN becomes dependency 
of AuthZ. We have use cases where access policy is not based on any 
identity, for example only possession of some kind of VC. In that case 
is AuthN still even needed?

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

Once again static client registration is not well specified in 
Soild-OIDC. I don't think there is even an interoperable way of using it 
across existing implementatiosn.


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

Do you have this web browser extensions use case captured in LWS UCs 
repo? To be honest I'm to familiar with how they work. For example what 
is used as a `redirect_uri`?


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

I was trying to shortly talk about it in my first video for TPAC 2024
https://www.w3.org/2024/09/TPAC/group-updates.html#solid

In short, there are diverse contexts where Solid can be used and on the 
technology level it needs to be flexible enough so it can be used in 
different ways.

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

To clearly document those limitations, we need to make sure we don't 
have misunderstandings. I think we may still have them on this mailing 
thread.

I'm happy to discuss alternative approaches. The most productive way for 
me would be to have all proposals, including Solid-OIDC, clearly showing 
how it satisfies (or not) all the relevant requirements from LWS UC 
repo.

We could also bring this topic up during Solid CG meetings, possibly LWS 
WG but I'm not a member of the WG. In Solid CG we could also schedule 
special topic meeting to dive into topic in a focused and hopefully 
productive way.

Kind regards,
elf Pavlik

Received on Monday, 28 April 2025 12:02:50 UTC