triauth

Delegation ​

Delegation lets another triauth identity act on your behalf. For example, it can sign in to a website as you. The other identity, called the actor, uses its own keys. You publish a record that grants the permission, and you delete the record to take it back.

Some examples:

  • An assistant handles a shared account for you, and websites still see that the assistant acted.
  • A service or an automated agent files reports or signs releases in your name, with keys of its own that you never copy.
  • A team identity such as support@example.com is operated by several people, each with their own identifier.
Delegation. John publishes an include record that names the assistant. The assistant signs in to the website with its own keys. The website reads John's grant and the assistant's keys from DNS, and signs the assistant in as John.john@example.comidentity records in DNSkey laptop[1/1]:BFj4…KT8cinclude assistant@example.com scope=app.example.com use=signassistant@example.comidentity records in DNSkey server[1/1]:BJSn…E1nQapp.example.comchecks the assistant's signaturechecks John's grantidentifier: john@example.comactor: assistant@example.comsigns as Johnreads the grantreads the keys
The actor signs with its own keys. The website accepts the signature because John's records grant it.

Grant a delegation ​

Add an include record to your identity records. It names the actor and the websites the grant applies to.

dns
john._at.example.com.   TXT   "include assistant@example.com scope=app.example.com use=auth,ping"

The record has three required parts and one option.

PartMeaning
includeMarks a delegation record. One record per grant.
assistant@example.comThe actor, the identity that may act for you, written as its identifier or as its identity domain. Use the identity domain when the actor's domain runs in private mode, for example _4GIBDU53B3._at.example.com.
scope=app.example.comThe websites the grant applies to, as host names separated by commas, or any for every website. Required. A grant without a scope does nothing.
use=auth,pingThe actions the grant covers: auth for sign-in, ping for background session checks, sign for signatures, stamp for stamps, and attest for attestations. Optional. Without it, the grant covers all five.

The domain policy ​

Your domain's record decides which delegations are allowed for everyone at the domain. The default allows grants to actors at any domain, and you can leave it as it is. If you want to restrict who people at your domain may delegate to, set a policy.

In the domain's recordAllowed grants
no include optionActors at any domain - same as include=any.
include=noneNone. Delegation is off for the domain.
include=localActors at the same domain only.
include=local,partner.exampleActors at the same domain and at partner.example.
include=anyActors at any domain.

For example:

dns
example.com.   TXT   "triauth auth.triauth.org mode=private include=none"

What websites see ​

A website that verifies a delegated sign-in learns both identities: yours as the account, and the actor's as the one who acted. It can accept or refuse delegated sign-ins, and it can check later that your grant still exists.

Revoke a delegation ​

Delete the include record. Websites that re-check sessions end the actor's sessions for your account at their next check.

Cautions ​

  • A grant names an identity, not a device. Every device the actor has, now or later, can act for you.
  • List the websites in scope whenever you know them. Use scope=any only when you must.
  • A grant to an actor at another domain stays valid if that domain expires and someone else registers it. Delete grants you no longer need.