Solid-OIDC and DPoP for decentralized identity in the fediverse

[erlend-sh]

Following from this issue and accompanying discussion..

dpop is in development for many years, and proven to be defacto standard. Now it is also an official rfc. Keycloak also landed support for dpop recently. It also enables to have decentralized identities.

I’d love to learn more about this. I’m particularly interested decentralized IDs in the context of federated application protocols such as ActivityPub and Matrix. Both have been mulling over various private-key approaches to this ideal state, but I suspect they’re trying to solve too many deep-rooted problems in one go.

https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101/
https://socialhub.activitypub.rocks/t/fep-c390-identity-proofs/2726

matrix-org/matrix-spec#246

With the convergence of OAuth/OIDC in both the primordial fediverse of ActivityPub (Mastodon & friends) as well as the federated Matrix, I see potential for OAuth self-hosting to serve the function of a minimum-viable ‘nomadic identity’. Combined with Solid’s WebID, it could graduate from the MVP stage to something very stable.

This Kitsune issue is an exploration into OAuth as a stepping stone towards what could later grow into a full-fledged Nomadic Identity, but starts off as just a personalized OAuth server.

An interesting thing about self-hosted auth is that you don’t even need it to be persistently online. There are use cases for it, but none that are essential.

For the fundamental act of logging into places, your self-hosted auth only needs to come online whenever you are trying to access an online space that asks for your authentication.

---

I think this could be a big deal for Solid as well. As a protocol it has struggled to find its footing in a mainstream use case. Unlike apub and Matrix, Solid doesn’t yet have a flagship application. Digital Identity (and just that, to start with) could be it.

I've restated this case here.

[damooo]

Indeed. Sovereign WebId, and associated authentication and authorization protocols are one of the primary contribution of solid ecosystem.

I’d love to learn more about this. I’m particularly interested decentralized IDs in the context of federated application protocols such as ActivityPub and Matrix.

Though i am not deeply familiar (yet) with fediverse protocols, i will elaborate on how webid + dpop + solid-oidc, enable decentralized, nomadic identity that can be provable.

1. Say a user has ownership over a web uri (https to be complete). Eg: https://eg.org/user#me, which he can use as his name. I.e. user themself is a resource, and it is their universal name. This will be their webid. From now onwards anyone can use this name to talk about them in rdf statements.
2. Webid is required to either derefer or redirect to a web document, which is known as webid-document. In above case uri of the webid-doc is https://ex.org/user. (different from https://ex.org/user#me).
3. This document is public for the span of the world of discource. It contain authoritative info about the user as an rdf graph.
4. They thus can have for example their pub-key. This can be used as one-of direct authentication mechanism too. See https://github.com/solid/authentication-panel/blob/main/proposals/HttpSignature.md
5. But user can also link to their oidc identity-provider.
6. Thus the main trick to decentalized id is this: User choose and own their id. That is dereferable. And links to their chosen (preferably self-hosted) oidc idp. Thus resource-servers (RS) and applications(RP) can trust the idp's mandate on user's identity.
7. When idp issues an id token to a client (RP), it can use that with any resource servers to act on behalf of user. (Scoped probably).
8. But an issue arises in decentralized ecosystem. I.e a malicious resource server can use that id token with other arbitrary resource-servers too.
9. Thus, it is imperative that, an id token issued by an idp must be scoped to a single client. This is what sender-constrainined-access-token do. DPoP essentially addresses this problem.
10. In dpop layered oidc, when client initializes oidc flow, it also sends it's public key to the idp. Idp, then "bounds" the id token to this pub-key. And it includes that pub key in id-token signed jwt payload.
11. Thus, when a client wants to use it at a resource-server, it should send a dpop-proof, along with the id token. That depop proof must be signed with the private key corresponding to the pub-key it previously used at idp.
12. Thus resource server can verify the proof against bounded pub key to asset that, token is being used by the same client to which it is granted.

This all together enables nomad identities.

@erlend-sh

[damooo]

webid-doc can also link to for example extended-social-profiles. There is also a client-client standard + vocab being developed to interoperably specify user's social profile.

Look at Webid profile.

[erlend-sh]

Thank you very much for this detailed response! 🙏 I quoted it in full here.

This is all looking increasingly amenable to what I think could be a really fun use case for Solid: https://blog.erlend.sh/weird-web-pages

[damooo]

Yes. Indeed. Solid enables interoperable, read-write, collaborative web. The storages not only serve pages, but can:

1. provide full read-write interface to the resource space.
2. Can also be collaborative, with WAC, ACP as access control protocols,
3. Can be interoperable, as the data is recommonded to be in rdf, and thus semantic. Thus semantics of data is not bound to single app. Data itself is enough to interpretate it.
4. Can be decentrailized with solid-oidc.

See also SolidOs project for initial client apps. I am also in process of creating an end-to-end semantic CMS based on solid. WIP.