Federated identity? Any interest in the Solid project that Tim Berners-Lee is doing?

ActivityPub
6

Does that really make it out of scope? For the Identity Proofs spec perhaps, but I think not for nomadic identity in general. I kinda want a domain-based identity coupled with a key-based identity. Isn’t Solid a good foundation to which key-based ID could be added?

This draft spec seems to be pointing in that direction: did:solid Method Specification

Meanwhile, here’s a Solid developer explaining how the protocol enables nomadic identities (without private keys?):

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

Further discussion here:

1 Like