tking/guildhouse-spire-plugins
SHA256
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update Shellstream specs for consent channels and HFL embedded ABI

Browse source 
Add consent-channels@guildhouse.dev SSH certificate extension for
advertising available consent transport channels. Add §8.6 to upper
layers spec describing HFL as the in-process capability boundary
within Shellstream sessions, with WIT as the formal contract.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Tyler King 2026-02-26 17:57:48 -05:00
parent 420a4e2ea0
commit 9319ad0ce8
2 changed files with 1126 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1074
docs/shellstream-spec-0001-upper-layers.md Normal file
View file

File diff suppressed because it is too large Load diff

53
specs/shellstream-extensions.md
View file

@ -69,7 +69,7 @@ document are to be interpreted as described in RFC 2119.
requirements for a tenant.
**Trust Domain**
: A SPIFFE trust domain (e.g., `guildhouse.io`) that defines the
: A SPIFFE trust domain (e.g., `guildhouse.dev`) that defines the
boundary within which SPIFFE identities and their associated
attestations are valid.
@ -324,6 +324,15 @@ credential issuance. It enables audit correlation between the SSH
certificate and the governance audit trail maintained by the
GovernanceService.
> **Security:** The `governance-intent` value MUST be set by the SSH
> Credential Composer from the actual `CreateIntentResponse.intent_id`,
> NOT from external input (e.g., requester-supplied headers). Verifiers
> SHOULD cross-check this value against the GovernanceService to confirm
> that the referenced intent exists, is in `redeemed` status, and
> corresponds to this credential's issuance. A syntactically valid but
> fabricated intent UUID would pass format validation but fail this
> cross-check.
**Example:**
```
governance-intent@guildhouse.dev = c8d9e0f1-2a3b-4c5d-6e7f-8a9b0c1d2e3f
@ -482,6 +491,48 @@ explicit version field. If a future revision deprecates or changes the
semantics of an extension, it MUST do so under a new extension name. The
original extension name retains its original semantics indefinitely.
### 10.5 `consent-channels@guildhouse.dev`
**Presence:** OPTIONAL.
**Value:** Comma-separated list of available consent transport channel
identifiers with no whitespace. Each channel identifier MUST match
`[a-z][a-z0-9]*(-[a-z0-9]+)*`.
Valid channel identifiers (corresponding to
`substrate:consent/channel.channel-kind`):
| Identifier | Tier | Description |
|------------------|------|------------------------------------------------|
| `local-tty` | 0 | Synchronous, local terminal prompt |
| `unix-socket` | 0-1 | Synchronous or async via Unix domain socket |
| `dbus` | 1 | Asynchronous, local D-Bus notification |
| `http-webhook` | 2 | Asynchronous, network HTTP webhook |
| `message-queue` | 2 | Asynchronous, network message queue |
| `store-forward` | 3 | Store-and-forward, delivered on reconnect |
This extension advertises the consent transport channels available on
the host that issued the certificate. Client modules use this
information to determine which consent tier is available for governance
operations requiring human or policy-automated approval. See
[GH-DESIGN-0005 §5](../../guildhouse-platform/docs/GH-DESIGN-0005-wasm-component-model.md)
for the tiered consent transport model.
The value parallels the `consent_channels` field in
`HostCapabilities` (SAT-SPEC-0001 §3.9). When both are present,
they SHOULD contain the same set of channels. If they differ, the
SAT's `HostCapabilities` is authoritative.
**Example:**
```
consent-channels@guildhouse.dev = local-tty,unix-socket,http-webhook
```
**Example (air-gapped host):**
```
consent-channels@guildhouse.dev = local-tty
```
## 11. References
- **OpenSSH PROTOCOL.certkeys** -- OpenSSH certificate format and