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

út 22. 4. 2025 v 22:45 odesílatel elf Pavlik <elf-pavlik@hackers4peace.net>
napsal:

> 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


Thanks Elf — I didn’t realize there’d been this much progress on SAI access
delegation, it’s looking really good. The delegation model feels like a
strong step toward real user autonomy — I’ll definitely take a closer look,
as I think I’ll need this too, quite soon.


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