specs/git_ns/right/ratify/v0_2/payload
library
Classes
-
BreakGlass
-
How a self-granted right came to be, and whether another administrator has since
ratified it. A record whose
breakGlass has no ratifiedBy is unratified: it
is live and published like any other right, it does not count toward the last-owner
or last-admin invariants, and any community administrator or namespace admin of its
namespace may revoke it. Ratification (git-ns/right/ratify) sets ratifiedBy and
ratifiedAt; from then on the record is an ordinary grant, and breakGlass stays
as its history. Never published to the Trust Registry.
-
Payload
-
An administrator other than its subject ratifies one unratified break-glass record,
turning it into an ordinary grant: it stops being flagged, and starts counting
toward the last-owner and last-admin invariants.
-
Response
-
The ratified record.
-
RightRecord
-
One recorded right. Implied rights (§4.2 of the rights model:
own implies
maintain implies commit.sign on the same resource; ns.admin implies
repo.create and own across its namespace) are not records and never appear as
RightRecords. A record carrying breakGlass was given by its subject to themselves
through git-ns/right/break-glass; it is a real right, published like any other, and
is shown with that flag on every surface that shows the record.
Extension Types
-
ElevatedRight
-
The three rights that carry authority over other people's rights:
git.ns.admin,
git.repo.create (which makes its holder the owner of every repository they
create) and git.repo.own. Separation of duties applies to these: nobody grants
one to themselves through git-ns/right/grant, or records one for themselves through
any other task that grants on the actor's own authority. The explicit self-grant is
git-ns/right/break-glass. git.repo.maintain and git.commit.sign are not
elevated.
-
Right
-
One of the five git rights. Each string is also the TRQP
action the VTC publishes
the right under in its Trust Registry, so it is carried verbatim. git.ns.admin
and git.repo.create apply to a namespace resource; git.repo.own and
git.repo.maintain to a repository resource; git.commit.sign to either.
Typedefs
-
Did
= String
-
A bare DID in the W3C DID Core syntax (§3.1):
did:, a method name of lowercase
letters and digits, :, and a method-specific id of colon-separated segments drawn
from A-Z a-z 0-9 . - _ and percent-encoded octets, the last segment non-empty. A
DID URL is not a DID: no path, query or fragment (/, ?, #), so a
verification-method id such as did:key:z6Mk…#z6Mk… is refused. Compared by exact
string equality — no case folding or percent-decoding. A consumer MUST still treat
the value as data: the pattern keeps shell metacharacters, whitespace and quotes
out of the wire form, but it does not make a DID safe to splice into a command or
markup.
-
Ext
= Map<String, dynamic>
-
Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a
reverse-DNS namespace; structure under each namespace is opaque to the framework.
-
Resource
= String
-
A forge-qualified resource, all lowercase:
<forge-host>/<owner> for a namespace,
or <forge-host>/<owner>/<repo-path> for one repository — github.com/acme,
github.com/acme/widgets, codeberg.org/acme. On a forge with nested groups
(GitLab) the repository path holds the subgroups between the top-level owner and
the project: gitlab.com/acme/platform/tools/cli is one repository of the
namespace gitlab.com/acme, and a subgroup such as gitlab.com/acme/platform is
not a resource. A repository path has 1 to 21 segments (GitLab: 20 levels of
subgroup and the project); GitHub and Forgejo repository paths are always one. The
forge is never implied: acme/widgets alone is not a resource. Containment is by
whole segment: github.com/acme contains github.com/acme/widgets and does not
contain github.com/acme-labs/x or codeberg.org/acme/widgets.
