Product positioning: make Auths adoptable as layered authority infrastructure

[bordumb]

Problem

Auths has a strong technical foundation, but the engineering story is currently clearer than the product story.

The repository combines cryptographic identity, public-key exchange, delegated authority, approval workflows, formal assurance, lifecycle management, and product integrations. Together these form a defensible authority platform. Presented all at once, however, they can make Auths appear too broad or costly to adopt.

A team that only wants to exchange Ed25519 public identities over Iroh, sign messages, or verify peers should not need to understand delegation graphs, capabilities, approvals, or formal evidence first.

The key risk is whether users can identify the smallest useful piece and adopt it without swallowing the entire system.

Proposed positioning

Auths lets software agents and services carry verifiable, tightly limited permission without sharing powerful long-lived credentials.

Explain Auths through three independently adoptable layers:

1. Identity and transport

   • create and represent keys
   • exchange public identities
   • sign and verify messages
   • integrate with transports such as Iroh
   • require no capability or approval concepts

2. Delegated authority

   • express who may perform which action
   • delegate authority to another principal
   • enforce that delegated authority can only become narrower
   • support independent and offline verification

3. Governance and approvals

   • human approval and enterprise policy
   • lifecycle management and revocation
   • receipts and audit evidence
   • domain-specific integrations

Users should be able to stop after any layer. Lower-layer APIs, examples, documentation, and dependencies should not force higher-layer concepts into the adoption path.

Outcome-oriented language

Lead with customer outcomes:

• stolen credentials have a smaller blast radius
• agents cannot quietly exceed delegated authority
• permissions behave consistently across languages
• decisions can be verified without trusting a central service
• auditors can determine exactly who authorized what
• teams can start with signed identity exchange and add delegation later

Formal methods should support these claims, not be the first concept a prospective user must understand.

Deliverables

• Define the primary V1 audience and one exceptionally easy workflow
• Publish a concise positioning statement and outcome-oriented supporting language
• Document the three-layer adoption model
• Audit dependency direction so identity and transport do not require capability or approval modules
• Add a minimal public-identity-over-Iroh example with no capability setup
• Add a delegated-authority example that introduces attenuation explicitly
• Present governance and approvals as an optional product layer
• Update README and launch material to lead with user outcomes
• Add architecture checks that preserve layer boundaries

Acceptance criteria

• A new user can explain Auths’ core value in one sentence.
• A team can exchange and verify public identities without importing capability or approval APIs.
• Delegation and approvals are presented as opt-in layers.
• Documentation maps technical mechanisms to concrete outcomes.
• The primary V1 workflow is explicit enough to guide roadmap and integration decisions.