NHID-Auth

NPIs are public. A caller can state one truthfully and still have no relationship to the organization it names. Behavioral controls establish that a caller disclosed itself as automated; they cannot establish that it was ever delegated authority to act for the provider it claims.

NHID-Auth addresses that with signed delegation rather than a registry or a gatekeeper. A provider signs a statement binding an agent’s public key to an NPI and a bounded scope. The receiving side verifies that signature offline — no lookup, no central authority, no service to call.

1. Provider signs a Delegation

   The provider organization holds an Ed25519 key pair and signs a Delegation naming its NPI, the agent’s public key, a scope, an expiry, the call SID and a key id.

2. Agent co-signs

   The agent signs over the delegation, producing an AgentPassport. Both signatures must verify; neither party can forge the other’s.

3. Presented to the receiver

   Drawn dashed above because it is not built: no adapter or SIP path carries a passport today. Credential delivery during a live call is an open design question.

4. Receiver verifies offline

   verify_passport checks the provider signature, the agent signature, expiry, call-SID binding, revocation and scope (at most three hops, narrowing only) against a trust anchor the receiver configured itself. No network call to NHID-Clinical, no registry, no NPPES lookup.

5. A result, then optionally a gate

   A VerificationResult is valid or carries an ERR_* code. When a deployment opts in, DLG-01 runs inside evaluate_all: DLG01_DELEGATION_VERIFIED lets the verified scope constrain PDX-01; an invalid delegation returns DENY_DATA.

6. An audit record

   Written either way, with the credential id, so the decision can be replayed. Revocation is durable within one deployment and does not propagate across organizations.

Reference An optional reference implementation, not deployed infrastructure. There are no production issuers.

v2 verifies that an AI agent is actually authorized by the provider it claims to represent. NPIs are public via NPPES — any caller can present a real one. v2 makes that insufficient.

AWhere v1.3 ends and v2 begins

Where this sits: v2 is the authorization layer of the trust stack, above the carrier layer (STIR/SHAKEN, which attests that a number is legitimate) and the v1.3 disclosure controls, and below the audit trail. The stack is drawn once, on the Evidence pack.

A tick in the v2 column means the reference implementation does this and the suite covers it. It does not mean the capability is deployed, operated, or available as a service. The last four rows are the ones that decide whether v2 could be run in production today, and three of them are Conceptual or Future. Standings follow claim-boundaries.md.

git clone https://github.com/NHID-Clinical/NHID-Clinical.git
cd NHID-Clinical
pip install -r requirements.txt
python -m pytest tests/test_identity.py -v   # v2 identity layer (43 tests)
python examples/issue_and_verify.py          # end-to-end credential walkthrough

• No registry or discovery mechanism for provider keys — open design question
• Credential delivery during live calls is not yet standardized
• Shadow pilot data will inform the formal v2 specification document

The reference implementation is live. If you want to test it against your own threat model or contribute to the formal specification, contact us.