Context

We are migrating the Arkavo Trust Network to a Chain-Driven Architecture (see arkavo-rs PR #44).
In this new model:

1. arkavo-rs (KAS) no longer makes policy decisions; it obeys on-chain SessionGrants.
2. The Chain (Ink! Contracts) issues these grants based on User Attributes.
3. authnz-rs (Identity Provider) must now anchor user attributes to the chain so the contract can verify them.

The Problem

Currently, authnz-rs likely issues JWTs or handles OIDC sessions locally. The Smart Contracts, however, cannot verify a JWT signed by a centralized server without expensive oracles.

To support the new architecture, authnz-rs must transition to being a Trust Anchor that publishes cryptographic commitments (Merkle Roots) of user attributes to the blockchain.

Proposed Architecture

1. Login: User authenticates via WebAuthn/OIDC as usual.
2. Mapping: authnz-rs maps the authenticated user to their Substrate Account ID.
3. Anchoring: authnz-rs calculates a Merkle Root of the user's attributes (e.g., role:admin, clearance:secret) and submits a transaction to the AttributeStore contract: set_root(user_account, merkle_root).
4. Proof Serving: When the User (Agent) wants to open a session on-chain, they call authnz-rs to get the specific Merkle Proofs required for the transaction.

Requirements

1. Add Substrate Connectivity

• Add subxt dependency (match version with arkavo-node, likely 0.38+).
• Configure CHAIN_RPC_URL and a RELAYER_PRIVATE_KEY (The account paying gas to update roots).

2. Implement Merkle Logic

• Use rs-merkle (or compatible library).
• Logic to hash attributes: H(namespace | name | value | salt).
• Logic to generate the Root from a list of user attributes.

3. Chain Synchronization (The Writer)

• Create a hook/worker: When a user's attributes change (or on first login), calculate the new Root.
• Submit extrinsic: AttributeStore::set_root(user_account, new_root).

4. New API Endpoint (The Reader)

The Agent needs proofs to send to the Smart Contract.

• GET /api/v1/attributes/proofs
• Auth: Bearer Token (Existing session).
• Response:

  {
    "root": "0x123...",
    "proofs": [
      {
        "attribute_hash": "0xabc...",
        "proof": ["0x...", "0x..."] 
      }
    ]
  }

Integration Check

This work is required to unblock the client-side SDK. The client will:

1. Login to authnz-rs.
2. GET /proofs.
3. Call arkavo-node -> request_session(proofs).
4. Call arkavo-rs (PR #44) -> rewrap(session_id).

References

• Arkavo KAS PR: Chain-Driven KAS with CBOR Protocol arkavo-rs#44
• Architecture Doc: [Link to internal doc if exists, or reference "Path B: Receipt Model"]