concepts ยท identity
Federation starts with names that can leave the app
A pod is only useful as an open data space if identities are not trapped in the product that happens to read it first. sempods treats people, apps and pods as addressable things.
The current reference implementation stores person permissions against WebID-style URIs. A user may sign in through an OIDC bridge today, but the grant is not written to "the Google account" or "the app account". It is written to an identifier the pod can reason about.
person WebID
|
| user-level grant
v
pod contexts
^
| delegated grant at consent
|
app DIDWebID and aliases
WebID gives a person a stable URI. sempods also carries aliases, such as a deterministic local URN or linked identity URIs, so a grant can still match when the same person is known through more than one address.
That matters for decentralization. A pod should not need one global account provider in order to grant access before someone signs in, move between identity providers, or federate with another deployment.
App DID
Apps are identified too. In the current model, pod-issued access tokens name the app through client_id, typically a DID-style identifier. The token also names the person as sub.
This is the pair the pod cares about: which person authorized which app. The app does not become the owner of the data; it receives the delegated reach the user consented to.
Two levels, one decision point
The reference implementation separates user-level grants from app delegation. At consent, the app receives the intersection of what it asks for and what the user may grant.
A broader user grant does not automatically mean every app receives that breadth.
Linked Open Data still has public edges
Public pod contexts remain readable without login. That is not a shortcut around authorization; it is the public part of Linked Open Data. A website, crawler, app or agent can dereference public resources and follow links.
Authenticated grants add private depth. The same resource can have public statements in one context and private statements in another. Federation does not require flattening those layers into one shared account system.
What is still moving
The vocabulary around aliases, WebID documents, app DID profiles and grant UX will continue to mature with the specification. The direction is already clear enough: identity should be linkable, grants should be revocable, and apps should be replaceable.