Internet-Draft draft-singh-apex-psi-03 July 2026
Singh Expires 20 January 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-singh-apex-psi-03-01
Published:
Intended Status:
Informational
Expires:
Author:
K. Singh
Apex Intelligence Empire / ROCKYFILMS888 PTY LTD

PSI-03: VPP Dispatch Conformance Attestation

Abstract

PSI-03 specifies a portable, Ed25519-signed bond that anchors a registered NDIS practitioner's professional identity to a DID-compatible decentralised identifier without requiring a central registry. The bond enables cross-provider, cross-border practice verification while preserving privacy and issuer sovereignty.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 January 2027.

Table of Contents

1. Introduction

Practitioner identity in the NDIS ecosystem is fragmented. Each provider maintains its own register. PSI-03 defines a sovereign identity bond that lets practitioners carry a single verifiable credential across all providers without either the practitioner or the provider depending on a central authority.

2. Bond Envelope

{ "psi": "03", "practitioner_did": "<did:apex:practitioner:...>", "registrar": "<issuer /.well-known URI>", "bonded_at": "<RFC 3339>", "expires_at": "<RFC 3339>", "credentials": [ { "type": "registration", "body": "<JWT or VC>" }, { "type": "qualification", "body": "<verifiable credential>" }, { "type": "endorsement", "body": "<verifiable credential>" } ], "signature": "<Ed25519 detached signature, base64url>" }

3. Verification

The verifying party MUST: 1. Resolve the registrar's Ed25519 public key from /.well-known. 2. Verify the bond signature. 3. Verify each presented credential's chain to a trusted root.

4. Security Considerations

A bond is not a proof of current registration. The verifying party SHOULD check the registrar's revocation list if real-time status is required.

5. IANA Considerations

None.

6. References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020. Author's Address Kawaljeet Singh Apex Intelligence Empire Balaclava, Victoria, Australia Email: kawaljeet.singh3008@gmail.com URI: https://apex-infrastructure.com