PROJECT IDENTITY DEVELOPMENT TEAM TECHNICAL NOTE TN-ID-001
RELEASE: PUBLIC DISTRIBUTION DATE: 15 JULY 2026
Subject:
Project IDENTITY, A Federated Authentication Protocol
Prepared by:Project IDENTITY Development Lead
For:Application Developers and Integration Engineers
References:RFC 6749, RFC 8414, OpenID Connect Core 1.0
Distribution:Creative Commons Attribution (CC BY 4.0)
§ 1 — Abstract

This technical note describes the operating principles of Project IDENTITY, hereinafter referred to as ID, a lightweight authentication subsystem developed to reduce the overhead of credential management across independently operated applications.

ID is a no-signup, no-password authentication service. Each user is assigned a UUID on first login; that UUID is the only value released to clients upon successful authentication. Users may attach any number of authentication methods to their account — email magic link, OTP, passkey, or trusted device — but those methods exist solely to verify identity, not to transfer it. Because UUIDs carry no sensitive information, the exposure from a compromised client flow is inherently bounded.

§ 2 — System Specifications
ProtocolOpenID Connect (OIDC), Authorization Code Flow
Authentication methodsEmail magic link, OTP, passkey, trusted device (user-configurable)
Claims releasedStable UUID (sub), verified email address. No additional claims.
Session persistenceCookie-based; subsequent authentications proceed without user interaction
Discovery endpointhttps://id.rac.so/.well-known/openid-configuration
Agent referencehttps://id.rac.so/AGENTS.md — full HTTP surface for developers and agents
LLM indexhttps://id.rac.so/llms.txt — curated endpoint index for language models
§ 3 — Client Registration Procedure

Application developers wishing to integrate with ID may register a client programmatically. No prior approval or coordination with the operating authority is required.

The registration request is issued as follows:

POST /clients  HTTP/1.1
Content-Type: application/json

{"redirect_uris": ["https://your-application.example/callback"]}

The authorization server responds with a client identifier and a client secret. The secret is returned exactly once at the moment of registration; standard secure-storage practice applies thereafter.

§ 4 — Security Analysis

The attack surface of the protocol is intentionally narrow. The maximum information disclosure resulting from a fully compromised client integration is bounded to a single verified email address per user. No correspondence, profile data, or auxiliary claims are accessible through this channel. Overall risk classification: LOW.

Approved By
@racso
Date of Issue
15 JULY 2026
Made with by Racso
TN-ID-001
Rev. July 2026