concepts · identity
Identity can travel. Authority stays with the pod.
A useful open data space needs to recognize who is acting without making each app the owner of the person's identity. It also needs to distinguish an app acting for a person from a service acting as itself.
People have addressable identities
The current contract identifies a person through a WebID URI. A pod can attach grants to that identity. An optional OIDC bridge lets the person sign in through an upstream provider.
The Kotlin identity service provides WebID profiles and that bridge. Trusted providers can assert equivalent WebID identities through the specified claim. The pod validates the assertion; similar-looking names do not establish that two identities belong to the same person.
Apps can act for a person
Delegated access uses Authorization Code with PKCE. The token identifies the person and client; the pod resolves the app's granted reach. An app receives the delegation the person approves within their own authority.
A calendar can stay a calendar
A person may read events and private notes. They can let a calendar app read the event Context without sharing the notes. The app does not automatically receive everything its user can access.
Services can act as themselves
A backend or scheduled worker uses Client Credentials. Its service identity and grants determine access; a person need not be online for every operation.
Kotlin 0.2 adds experimental registration, owner consent and management for these services. The owner can choose their reach, narrow it or revoke it. Those setup extensions are described in the release's service-access guide.
Public data is still public
An anonymous caller can read public Contexts. Authenticated access can add private depth to the same resource. Each pod applies its own decisions; linking data does not establish a shared account or grant access elsewhere.
Authorization contract Identity and trust Service access Explore MCP