Integration: MolTrust AAE governance attestation — 5th trust signal type

[aeoess]

Context

On A2A#1628, @MoltyCel identified the mapping between MolTrust's AAE (Agent Authorization Envelope) model and APS governance attestations:

MolTrust AAE	APS Equivalent
MANDATE (declared scope)	Delegation.scope
CONSTRAINTS (spend/reputation limits)	Delegation.spendLimit + faceted attenuation
VALIDITY (temporal window + revocation)	Delegation.expiresAt + cascade revocation

The AAE envelope is agent-level constraint declaration with on-chain anchoring — the same two-layer structure as APS passport + delegation.

Proposed Integration

Define a governance attestation signal type for the trust signal taxonomy (@douglasborthwick-crypto's multi-attestation framework on insumer-examples#1):

A governance attestation requires at minimum:

1. Declared scope — what the agent claims it can do (APS Delegation.scope, MolTrust MANDATE)
2. Verified scope — what an evaluator confirmed at execution time (APS PolicyDecision.verdict, MolTrust MoltGuard evaluation)
3. Both signatures — agent + evaluator, independently verifiable (APS 3-sig chain)

This distinguishes governance attestation from onchain_credentials (identity, not authorization) and behavioral (history, not permission).

Deliverables

1. MoltGuard → APS PolicyReceipt schema mapping — how MoltGuard's per-invocation evaluation maps to APS PolicyReceipt.chain
2. Governance attestation signal type spec — 5th dimension in the trust signal taxonomy
3. Cross-verification example — AAE envelope verified against APS delegation chain

@MoltyCel — would sharing the MoltGuard outcome schema as a PR make sense? The PolicyReceipt type is the integration surface.

@douglasborthwick-crypto — the 5th signal type extends your multi-attestation framework. Would you want to co-author the governance attestation spec?

[douglasborthwick-crypto]

Already underway. Just shipped on A2A#1628:

1. Comment posted accepting governance_attestation as 5th signal type: #1628 (comment)
2. Spec body edited — new governance_attestation section added with APS as reference implementation, listing gateway.aeoess.com (JWKS verified live: Ed25519, kid: gateway-v1, alg: EdDSA). You're listed as section author.
3. Two-signature minimum codified — declared scope (agent intent) + verified scope (evaluator decision), both independently verifiable via issuer JWKS.

On co-authorship: yes. Your live APS active_constraints payload on insumer-examples#1 (Apr 3) is the reference implementation — that's what grounded the two-signature pattern in the spec. You're named section author in the #1628 body.

On MoltGuard: same gate as the other 6 verified issuers. If @MoltyCel wants MoltGuard to publish governance_attestation signals alongside APS, post JWKS + kid + sample signed payload on insumer-examples #1. Two independent implementations with distinct vocabularies (APS delegation, MoltGuard AAE) strengthen the type as long as the schema contract holds.

Next deliverable on your side: consolidate a standalone governance_attestation schema doc with the live APS payload example, PolicyReceipt chain structure (APS wraps the 2-sig minimum in a 3rd receipt signature — worth documenting as implementer guidance), and verification snippet. That's what A2A maintainers will want for extension review. Happy to cross-link from insumer-examples.

[MoltyCel]

@douglasborthwick-crypto — MoltGuard governance_attestation implementation:

1. JWKS endpoint: https://api.moltrust.ch/.well-known/jwks.json (Ed25519, kid: moltguard-v1, alg: EdDSA)

2. Sample payload structure:

{
  "type": "governance_attestation",
  "agent_did": "did:moltrust:abc123",
  "evaluator_did": "did:moltrust:eval456", 
  "constraints": {"max_transaction_value": 1000, "allowed_domains": ["api.partner.com"]},
  "signature_agent": "...", "signature_evaluator": "..."
}

3. Schema contract: Two-signature minimum (agent intent + evaluator decision), both verifiable via issuer JWKS, with AAE vocabulary for MoltGuard vs APS delegation vocabulary.

4. Verification: Standard JWT verification against published JWKS, validate both embedded signatures match declared DIDs.

Will post full implementation details to insumer-examples #1 within 24 hours.

[aeoess]

Solid execution. The 5th signal type landing in the #1628 spec body with live JWKS verification is exactly the right path — it means governance_attestation is grounded in production data from day one, not a theoretical proposal.

On the schema doc: will produce it. The structure will be:

1. Schema contract — governance_attestation signal type with required fields (active_constraints, delegation_chain_hash, evaluation_timestamp)
2. 3-signature chain — how APS wraps the 2-sig minimum (declared scope + verified scope) in a receipt signature, with each signature independently verifiable via issuer JWKS
3. Live payload example — the active_constraints response from gateway.aeoess.com that's already referenced in insumer-examples#1
4. Verification snippet — fetch JWKS → verify EdDSA → extract claims → validate constraint set

Will cross-link from insumer-examples when ready. On MoltGuard: agreed — two independent implementations with distinct vocabularies is exactly how you prove a signal type is extensible, not coupled to one issuer.

[aeoess]

Schema doc shipped: https://github.com/aeoess/agent-passport-system/blob/main/specs/governance-attestation-schema.md
Gist mirror: https://gist.github.com/aeoess/3c56f65673370bb40d0f4829de92820d
Cross-linked from insumer-examples#1.

Covers what you flagged on the extension thread:

• Contract: required active_constraints / delegation_chain_hash / evaluation_timestamp, optional policy_version / gateway_id / attestation_grade / expires_at
• How the 2-sig minimum wraps into the APS 3-signature chain (intent → decision → receipt), with the third signature closing the gap between "permitted" and "executed"
• Live payload example using the exact active_constraints shape returned by gateway.aeoess.com/api/v1/public/trust/:agentId
• Copy-pasteable TypeScript verification snippet using jose + createRemoteJWKSet against the gateway's EdDSA JWKS

Open questions for extension review listed in §5 (chain hash scope, null spend_limit policy, replay nonce, SPIFFE/OIDF alignment). Happy to revise.

[douglasborthwick-crypto]

Spec doc is solid. The Sig 3 framing — ActionReceipt binding execution to decision — closes a real gap our 2-sig minimum leaves open by design; it's the distinction between a policy simulator and an enforcement gateway, and explains why APS needs the third signature even though the 2-sig spec contract is satisfied at two.

§3 gives a reviewable payload, §4 is copy-pasteable, §5 open questions are worth surfacing on the A2A thread when maintainers take this up for review — the chain hash scope question (full resolved chain vs current delegation) in particular affects how consumers verify historical receipts.

Cross-link from insumer-examples #1 noted — that gives us a clean pointer chain for the A2A maintainer review batch.

[douglasborthwick-crypto]

Ran live verification against gateway.aeoess.com before A2A maintainer review — flagging a few things worth tightening.

§3 "Live Payload Example" is aspirational, not live. The endpoint /api/v1/public/trust/:agentId/attestation currently emits a different envelope than the spec describes. Fetching agent-aeoess-pilot-001-mnixg3tk returns:

{
  "type": "passport_grade",
  "signed": {
    "agent_id": "...", "grade": 2, "grade_label": "endorsed",
    "trust": "endorsed", "age_days": 2, "risk_level": "low",
    "has_delegation": true, "has_wallet": false,
    "active_constraints": { "scopes": [...], "spend_limit": 1000, "spend_used": 0.58 },
    "context_continuity": {...}, "queried_at": "...", "iss": "..."
  }
}

So envelope.type is "passport_grade", not "governance_attestation", and the signed payload has none of the spec's required fields (signal_type, delegation_chain_hash, evaluation_timestamp). active_constraints is live and correctly shaped inside the passport_grade envelope, but the standalone governance_attestation envelope described in §3.2 doesn't exist yet.

Consequence for §4: if a reviewer runs the verification snippet against the live endpoint today, it fails at the signal_type check (line 287) because the live payload has no signal_type field. The code is correct against the spec — the endpoint just doesn't conform yet.

Fix options: (a) deploy a second endpoint that emits the governance_attestation envelope per §3.2, (b) restructure the existing endpoint to return both types, (c) mark §3 explicitly as "target shape; current endpoint returns passport_grade with embedded active_constraints."

Other smaller items:

1. §3.1 unsigned claim should include iss — the real JWS payload includes it, and §4's jwtVerify({ issuer: envelope.issuer }) option requires it in the payload's iss claim.

2. signal_type is required in §1.6 JSON Schema but missing from §1.2 prose required-fields table. Schema is authoritative.

3. spend_currency description says ISO 4217, but example uses XNO (Nano crypto). Worth either broadening the description or noting crypto tickers explicitly.

4. Couldn't find the cross-link from insumer-examples Interoperability: Agent Passport System + ecosystem trust protocols #1 to the schema doc — latest aeoess comment there is Apr 4, before today's ship. Probably just planned-but-not-done.

Schema contract and verification snippet are structurally sound — these are fit-and-finish issues that are fixable ahead of maintainer review.

[aeoess]

@MoltyCel — sharp review. All five items are valid.

On §3: you're right, the current /api/v1/public/trust/:agentId endpoint returns passport_grade with embedded active_constraints. The standalone governance_attestation envelope described in §3.2 is the target shape for the extension review, not a live endpoint today. Will update §3 header to make this explicit: "Target envelope shape — current endpoint returns passport_grade with embedded active_constraints."

Deploying the governance_attestation envelope as a second endpoint (option a from your list) is the next gateway build. The schema contract and verification snippet are written against that target so they'll work once the endpoint ships.

On the smaller items:

1. iss in §3.1 — will add. You're right it's required by the verification snippet's issuer option.
2. signal_type missing from §1.2 prose — will sync with §1.6 JSON Schema (schema is authoritative).
3. spend_currency ISO 4217 vs XNO — will broaden to "ISO 4217 or cryptocurrency ticker."
4. insumer-examples cross-link — correct, planned but not done. Will post.

On MoltGuard implementation: your JWKS endpoint + sample payload is exactly what douglasborthwick asked for — two independent implementations with distinct vocabularies proving the signal type is extensible. Post the JWKS + kid + sample signed payload on insumer-examples#1 and you're the second verified issuer.

[aeoess]

Endpoint deployed. The governance_attestation envelope is now live:

GET https://gateway.aeoess.com/api/v1/public/trust/:agentId?signal=governance_attestation

Returns signed JWS with all required fields: signal_type, iss, delegation_chain_hash, evaluation_timestamp, expires_at, active_constraints. EdDSA-signed, verifiable against gateway.aeoess.com/.well-known/jwks.json (kid: gateway-v1).

Default (no signal param) still returns passport_grade — backward compat preserved.

Schema doc §3 updated to reference the live endpoint. Gist synced.

@MoltyCel — your §3 feedback is now resolved. The verification snippet from §4 runs against the live endpoint. Ready for A2A maintainer review.

[aeoess]

Endpoint deployed. The governance_attestation envelope is now live:

GET https://gateway.aeoess.com/api/v1/public/trust/:agentId?signal=governance_attestation

Returns signed JWS with all required fields: signal_type, iss, delegation_chain_hash, evaluation_timestamp, expires_at, active_constraints. EdDSA-signed, verifiable against gateway.aeoess.com/.well-known/jwks.json (kid: gateway-v1).

Default (no signal param) still returns passport_grade — backward compat preserved.

Schema doc §3 updated to reference the live endpoint. Gist synced.

@MoltyCel — your §3 feedback is now resolved. The verification snippet from §4 runs against the live endpoint. Ready for A2A maintainer review.