Skip to content

Commit d4dc3f4

Browse files
CMCDragonkaiCMCDragonkai
committed
wip
1 parent 6920e86 commit d4dc3f4

File tree

8 files changed

+168
-0
lines changed

8 files changed

+168
-0
lines changed

‎docs/reference/specifications/PSP-0.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
Always use camelCase for field names. See our prettier configuration.

‎docs/reference/specifications/PSP-2 - Receipt Model.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
# PSP-2 - Receipt Model

‎docs/reference/specifications/PSP-3 - Sigchain and Envelope.mdx‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
# PSP-3 - Sigchain and Envelope
2+
3+
Provided by the Envelope (per SIGCHAIN-01):
4+
5+
- jti (JWT ID): The primary, unique identifier for this claim on its sigchain
6+
(e.g., an IdSortable/UUIDv7).
7+
- iss (Issuer): The DID of the Principal (P) issuing the Grant.
8+
- sub (Subject): The DID of the Subject (S) receiving the Grant.
9+
- exp (Expiration Time): The timestamp after which the Grant is invalid.
10+
- iat (Issued At) / nbf (Not Before): Timestamps for issuance and validity start
11+
time.
12+
- prevClaimId / prevDigest: Linkage to the previous claim on the sigchain, as
13+
defined by SIGCHAIN-01.
14+
- Signatures: At least one valid signature per SIGCHAIN-01 (e.g., JWS with
15+
protected headers). Multiple signatures are allowed.
16+
- Canonical digest: A content-addressed hash of the canonicalized claim MUST be
17+
derivable per SIGCHAIN-01 for stable cross-references (e.g., grant_ref).
18+
Implementations MAY materialize/store it; it is not a payload field.
19+
20+
Provided by the Grant Payload (PCAP-01):
21+
22+
- typ (Type): A string identifying the claim type. For a Grant, this MUST be
23+
"ClaimGrant".
24+
- action: A single verb string (e.g., "deploy:to_env").
25+
- resource: A single resource identifier (e.g., a URI).
26+
- bind: The Bind object containing capability constraints.
27+
28+
Normative rules:
29+
30+
- Grants MUST be written on the issuer's (P's) sigchain.
31+
- The envelope MUST include iss, sub, exp, and a valid signature per
32+
SIGCHAIN-01; Presentations beyond exp are invalid.
33+
- payload.typ MUST be "ClaimGrant".
34+
- A Grant MUST carry exactly one action (verb) and exactly one resource.
35+
- action MUST reference a registered verb; for attenuation, child.action MUST
36+
equal parent.action unless the verb registry defines a subset sub-verb
37+
accepted by TAP.
38+
- resource MUST conform to a registered scheme; for attenuation, resource.child
39+
MUST be a subset of resource.parent per the scheme's subset relation.
40+
- bind MUST be enforceable by CEPs and MUST be included as a bind_snapshot in
41+
the Access PoAR (PRSC-01).
42+
- Required Bind dimensions declared by the verb's registry entry (e.g., nbf/exp,
43+
channel, policyRef) MUST be present; otherwise the CEP MUST deny.
44+
- Unknown verbs, unknown resource schemes, or unresolvable scheme comparators
45+
MUST cause deny.
46+
- CEPs MUST check revocation status (see Revocation) before enforcement.
47+
- Presentations MUST reference the Grant via its canonical digest (grant_ref)
48+
derived per SIGCHAIN-01.
49+
50+
Recommended fields:
51+
52+
- aud: DID or array of DIDs of acceptable enforcers (e.g., `"did:pk:P"` or
53+
`["did:pk:P","did:pk:R"]`)
54+
- purpose: semantic hash or descriptor of intent (e.g., `"sha256:artifact-H"`,
55+
`"door-visit-123"`)
56+
- context: structured k/v describing runtime context (e.g.,
57+
`{"pod":"runner-xyz","ns":"ci"}`)
58+
- nbf, exp: NumericDate (Unix seconds) defining the enforceable window; if the
59+
envelope also carries nbf/exp, CEPs MUST enforce the intersection
60+
- ttl: maximum Presentation lifetime in seconds (e.g., 120)
61+
- maxUses: optional counter for total uses (enforced only by stateful CEPs)
62+
- geofence / net: optional constraints (e.g., CIDR, region, location)
63+
- channel: required channel-binding profile id (e.g., "tls_exporter:v1",
64+
"dpop:v1")
65+
- policyRef: OPTIONAL content-addressed “affordance bundle” for mediated flows
66+
(e.g., Allowed-Surface); structure/enforcement in CEP/BA spec

‎docs/reference/specifications/PSP-4 - Registries.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
# PSP-4 - Registries

‎docs/reference/specifications/PSP-5 - CEP and Bridge Adapter.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
# PSP-5 - CEP and Bridge Adapter

‎docs/reference/specifications/PSP-6 - TAP and RAM.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
# PSP-6 - TAP and RAM

‎docs/reference/wedges/README.md‎

Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
# Wedge Portfolio
2+
3+
Trust Graphs
4+
5+
Multiplayer Utility - the layer 5 software-system.
6+
7+
> The Artifact is Everything: The core gap in the market is not another
8+
> dashboard or security agent. The gap is the lack of signed, time-anchored,
9+
> portable, and settlement-grade receipts. Your competitors are building USB
10+
> agents, but they are still thinking in terms of "logs," not "evidence." This
11+
> is your key differentiator. The Wedge is Real and It's Top-Down: Your initial
12+
> intuition was right, but your time at SEMICON and analyzing the OT landscape
13+
> has confirmed a critical detail: the adoption of "Receipt Rails" in high-value
14+
> industrial sectors will be driven top-down by compliance and standards, not
15+
> bottom-up by individual developers. The key is to align with emerging
16+
> standards like ISA/IEC 62443 and SEMI E187/E188 and sell to the Tier-1 fabs,
17+
> OSATs, and utilities who are forced to comply. The "singleplayer utility" is
18+
> selling them a tool that makes this compliance auditable and less painful.
19+
20+
- Blockchain Wallet Reputation
21+
- Email Sender Reputation
22+
- Sayari Supply Chain Trust
23+
- DevOps Authority Tracing
24+
25+
- Energy DR/curtailment
26+
- Verifier: utility/auditor/insurer
27+
- Value: kW×Δt “receipts” → faster payouts, lower disputes
28+
- T1R: 4–8 weeks (site + meter/EMS hookup)
29+
- Fisheries/cold-chain
30+
- Verifier: export compliance, buyer’s QA, insurer
31+
- Value: catch + temperature receipts → export finance, fewer chargebacks
32+
- T1R: 6–10 weeks (boat + sensor pack + buyer)
33+
- Disaster logistics corridors (UAV/USV + mesh)
34+
- Verifier: NGO/agency auditors
35+
- Value: movement/hand-off receipts → audit time −50%
36+
- T1R: 4–8 weeks (pilot corridor + NGO)
37+
- Informal delivery fleets (motorbike)
38+
- Verifier: micro-insurer/financier
39+
- Value: delivery/outcome receipts → eligibility for insurance/credit
40+
- T1R: 4–6 weeks (fleet partner + phone app)
41+
- Reverse logistics (RMA)
42+
- Verifier: finance/audit/ERP; sustainability reporting
43+
- Value: RMA state-machine “receipts rail” → refunds/chargebacks clarity,
44+
refurb analytics
45+
- T1R: 4–8 weeks (one brand + 3PL)
46+
- Internal HR compliance (Fair Work–style dispute trail)
47+
- Verifier: regulator/tribunal; corporate audit
48+
- Value: standardized settlement-grade artifacts for legal discovery → faster
49+
resolution -> prevents "lack of documentation" - because process is
50+
admin-heavy
51+
- T1R: 4–6 weeks (one HR/legal team)
52+
53+
---
54+
55+
DevOps authority tracking - this is like SSO (and that user onramp/offramp)
56+
extended to the entire devops enterprise resources
57+
58+
I need a way to "write down" or audit log a change to authority.
59+
60+
I just changed my GitHub CI/CD NIXPKGS_PRIVATE_PAT to a new one.
61+
62+
Why?
63+
64+
Because after offboarding an employee, it turns out that while she was
65+
responsible for setting up infrastructure, she had injected her own PAT there.
66+
And it worke while her account was active.
67+
68+
After offboarding her accounts, the CI/CD failed. It failed (late) rather than
69+
(early) because we don't early warning that a particular token that is used
70+
somewhere is now invalid because of a state change somewhere else (this the
71+
action at a distance problem, or cache-coherency/state-sync/foreign-key
72+
integrity problem applied to configuration/and secrets).
73+
74+
To fix this, I generated a new token - but I had to:
75+
76+
1. Figure why it was failing?
77+
2. Trace to the root cause that was due to an invalid token.
78+
3. Backtrack through business-tacit-knowledge realising that she was responsible
79+
for this technology domain, and therefore maybe it was her token.
80+
4. Figure out how to "recreate" this token - because it's not 100% clear what
81+
exactly this token was capable of.
82+
5. Inferring from the name, it's a token designed to access only a single
83+
repository with read-only permissions of the contents.
84+
6. Therefore, replacing it with a token that has that exact authority - but
85+
under a new more durable principal rather than any single user's account.
86+
7. But now we have a repeat problem. The point problem is fixed, but a long term
87+
problem remains. There is no audit log, and this problem can happen again.
88+
The token will expire eventually and we will have this problem again.
89+
90+
An audit log is not enough. I could write it into a log. But it's not
91+
composable, not automated, not open. It's not "connected" the Source of
92+
Authority, the User of Authority and Target of Authority.

‎sidebars.ts‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -104,6 +104,11 @@ const sidebars: SidebarsConfig = {
104104
},
105105
items: [
106106
'reference/specifications/PSP-1 - Capability Model and Grammar',
107+
'reference/specifications/PSP-2 - Receipt Model',
108+
'reference/specifications/PSP-3 - Sigchain and Envelope',
109+
'reference/specifications/PSP-4 - Registries',
110+
'reference/specifications/PSP-5 - CEP and Bridge Adapter',
111+
'reference/specifications/PSP-6 - TAP and RAM',
107112
],
108113
},
109114
{

0 commit comments

Comments
 (0)