ANTRequest's FaviDiD Specification (Version 0.3.0)

warning! the bar for Reasonably Capable Shared Hosting, might be set too high.

FaviDiD is a Brand New way to Decentralized Identify you. using some cryptography Math you can identify yourself using a Private Key to sign your Requests and a Public Key for the service to verify it is from you.

to use FaviDiD you can use This Specification to insure interoperability. If you do not Like where this is going please fork.

Table Of Contents

Status of this document

this document written on Thu Mar 12 2026 is Semantic version 0.3.0. this document is self-published independently.

i am still Figuring things out. this is not final design and might be vague, impossible, or otherwise not implementable. im still seeking to bring this closer to my vision.

This Specification Depends On

Foundation: (0.2.0)

This Specification uses external references

Key Generation

use the Ed25519 and create a Private-Key and a Public-Key, store them securely.

Decentralized id (FaviDiD way)

To create a Decentralized id, MUST follow these steps

$Result is string did:favidid:.
set $Result to the concatenation of $Result and ed25519:.
Info! future Specifications MAY allow other algorithms, this one doesnt.
$publicKey is the raw 32 bytes of Public-Key.
set $publicKey to the encoded bytes of $publicKey using base58 (Bitcoin alphabet, no padding).
$Result is $Result concatenated with $publicKey.
Return $Result.

Decentralized id (W3C did:key way) (equivalent)

This produces a standard did:key identifier using the exact same raw 32-byte Ed25519 public key. It is fully equivalent for signing and encryption purposes in this suite.

$publicKey is the raw 32 bytes of the Public-Key.
Prepend $publicKey with the single byte 0xed (multicodec prefix for Ed25519 public key).
Encode the resulting 33 bytes ($publicKey) using base58 (Bitcoin alphabet, no padding).
Prepend the encoded string ($publicKey) with z (multibase prefix for base58-btc).
Prepend the result ($publicKey) with did:key:.
Return the final string.

Key usage

Authentication

authentication happens as follows in order.

the Edge MUST HTTP POST /Favicond_/favidid/auth to the Planet. with F-FaviDiD: set to the user's FaviDiD. if the Edge possesses a non-expired PlanetaryCode for this Planet, the Edge SHOULD send Authorization: PlanetaryCode <PlanetaryCode>
If the <PlanetaryCode> is a non expired session token, the planet MAY skip to Successful Authentication.
if the Request does not contain a valid Authorization corrosponding to a valid user in the Planet's data, the Planet MUST respond with 401 and WWW-Authenticate with a FaviDiD challenge. FaviDiD challenge is described below. a Planet MAY add other FaviDiD Challenges but FaviDiD0-3 MUST be present for this specification.
1. Generate a Nonce and keep it for 300 Seconds. how you create the Nonce is Planet-defined but MUST be within the base58 alphabet. Nonce MUST be >=128 bits entropy (e.g. 22–32 random bytes -> base58, resulting in ~30–44 chars). Planets MUST NOT generate nonces shorter than 16 bytes.
2. associate the Nonce with the F-FaviDiD:.
3. Inset the just generated Nonce in the Nonce field.
the Edge MUST prompt the user with the Realm, the User MUST give informed consent to sign the challenge. the Refuse and Accept button MUST be displayed equally visible.

Info! This should be common sense, but look what cookie banners have become. now user can claim its a protocol violation. normally this wouldnt make it ino the spec as i dont dictate UI.
If the user does not consent, the Edge MUST abort the operation.
If the user consents. the Edge MUST HTTP POST /Favicond_/favidid/auth with one of the following in the Authorization Header (concatenated),
1. the FaviDiD challenge chosen and then a space
2. the Base 64 Url equivalent of
```
{"typ":"JWT","alg":"EdDSA","proto":"FaviDiD-Auth"}
```
  and then a dot (which is eyJ0eXAiOiJKV1QiLCJhbGciOiJFZERTQSIsInByb3RvIjoiRmF2aURpRC1BdXRoIn0.) which is the JWT Header.
  Info! the exact string is Edge-Defined, as long as these properties match these values after verifying and decoded.
3. the JWT Payload described below and then a dot.
4. the signature. signed by the private key of the one login in. sign the Base 64 Url JWT header and Base 64 Url JWT Payload separated by a dot.
The Planet MUST do the following in any order
- Verify the Signature of the JWT as Received, using the Ed25519 algorithm, if that alg isnt EdDSA the Planet MUST skip to authentication Failure.
- Verify the JWT's aud claim is equal to the Domain.
- Verify the JWT's iss and sub are equal and are equal to the FaviDiD associated with the Nonce.
- Verify the current time is within the JWT's nbf and exp. ignore iat.
- Verify the JWT's nonce claim is correct.

Perform either one the following

successful authentication.

planets MUST respond with Status Code 200 Content-Type: application/json and with the following

Name	Value	Where
`proto`	MUST be set to `FaviDiD-Auth`.	Body
`success`	MUST be set to the JSON value `true`.	Body
`PlanetaryCode`	MUST be a Cryptographically Secure Session token of Planet-Defined generation. the cookie expiration advertised MUST be when the session token expires. MUST set the `Secure` flag, SHOULD set the `HttpOnly` flag.	`Set-Cookie`
`nonce`	MUST be set with the actual Nonce used for verification above, exactly.	Body

authentication Failure

planets MUST respond with Status Code 401 Content-Type: application/json

{
    "proto": "FaviDiD-Auth",
    "success": false
}

The HTTP Retry-After Header SHOULD be set (MUST be either an integer number of seconds (e.g. 300) or an HTTP-date string (RFC 7231).) Indicating how long an Edge SHOULD wait before retrying. if the value signals a date after 1 hour compared to the HTTP Date Header the Edge MUST abort automatic Retries, and SHOULD honor the Request, only retrying at User Request. if not set Edges SHOULD interpret Retry-After: 15

the response's Content-Type is not application/json

The Edge MUST NOT automatically Retry, the Edge MUST inform the user the feature is unsupported. the Response body SHOULD be ignored.

FaviDiD challenge

a FaviDiD WWW-Authenticate Challenge or FaviDiD challenge is a string as Follows

A FaviDiD challenge MUST start with FaviDiD.
A FaviDiD challenge MUST have the major version number directly concatenated after FaviDiD.
If the major version is 0 (zero) then dash and the minor version MUST added.
A FaviDiD challenge MUST have a Realm param.
A FaviDiD challenge MUST have a Nonce param.
Other Version's FaviDiD MAY have different meanings and requirements, a FaviDiD challenge the implementation does not support MUST be ignored.

FaviDiD challenge (examples) (non-normative)

Valid ones include

FaviDiD0-2 Realm="My Realm" Nonce="2XPKHzVg52jDEiaaBt2Y5BAT"
FaviDiD0-72 Realm="My Other Realm" Nonce="31wKW5ctCqfXyWgjj7cHpivv"
FaviDiD35 Realm="antRequest.nl" Nonce="332JGNeGUaa3gSwYdqLekFUa"
FaviDiD1 Nonce="34DgnzKxSTm7uYrh4smyyGsx" Realm="index.php"

invalid ones include

FaviDiD0-2 Nonce="nbD8axZqv5Z97d9Cu8gwab" (omits Realm)
FaviDiD0-2 Realm="My Other Realm" (omits Nonce)
FaviDiD1.3 Nonce="2VnLaWqgpTQPVA7QuGapN733" Realm="index.php" (uses dot instead of minus)
FaviDiD.3 Nonce="bhjE5sfhnRyEwiAA5XzaWX7" Realm="index.php" (no major version)

FaviDiD JWT Payload

the Payload MUST or MUST NOT have the following claims.

Claim Name	Claim Value
`exp`	SHOULD be set 300 integers higher than `iat`. Info! For Clock Skew.
`iat`	MUST be set to the current time utc since the epoch of `1970-01-01T00:00:00.000Z`. Info! Clock Skew doesnt apply here.
`aud`	MUST be set to the Planet's Domain (it is assumed to be HTTPS as Edges and Planets MUST NOT use plain HTTP.
`iss`	MUST be set to your did (FaviDiD).
`sub`	MUST be set to your did (FaviDiD).
`nbf`	SHOULD be set 50 integers lower than `iat`. Info! For Clock Skew.
`jti`	MUST be set to an uuid (is ignored in this specification, Planets MAY use this in a Planet-Defined way).
`nonce`	MUST be set to the Nonce given by the Planet.

Did Resolution

FaviDiD Overview: FaviDiD uses two resolution paths — a restricted profile of did:key (Ed25519-only) and a new lightweight method did:favidid:ed25519:... optimized for raw key operations.

Did Resolution (Full)

The Did Resolution (Full) Algorithm only applies to Decentralized id (W3C did:key way) DiDs. for Decentralized id (FaviDiD way) DiDs use Did Resolution (Basic)

To resolve a did:key (did-key), Decode did-key using https://w3c-ccg.github.io/did-key-spec/ and Store the result in did-doc. check conformance with the following RuleSet

Only Ed25519 public keys are accepted (multicodec prefix 0xed).
Resolution MUST fail (return error / null) for any other key type.

If everything succeeds Return the raw bytes of the Public Key.

Alternative Flow

If everything succeeds, an Implementation MAY choose to return the DID Document produced by the spec's algorithm.

Did Resolution (Basic)

The Did Resolution (Basic) Algorithm only applies to Decentralized id (FaviDiD way) DiDs. for Decentralized id (W3C did:key way) DiDs use Did Resolution (Full)

To resolve a did:favidid (did-favidid), SHOULD follow these steps

Set $match to the result of matching did-favidid against /^did:favidid:ed25519:(.+)$/
If no match, return null.
Set $base58Part to $match capturing group 1.
Decode $base58Part using base58 (Bitcoin alphabet, no padding) to get $publicKeyBytes.
If decoding fails or length of $publicKeyBytes != 32 bytes, return null.
Validate $publicKeyBytes as a valid Ed25519 public key (e.g., point on curve, proper encoding).
If invalid, return null.
Return $publicKeyBytes (the raw 32-byte Ed25519 public key).

Security Considerations

ThreatModel

This specification assumes the Planet is hosted on a Reasonably Capable Shared Hosting Server as defined in Foundation 0.2.0.

This specification assumes attackers can:

Read, modify, and inject network packets
Attempt replay attacks
Submit malformed or malicious JWTs

The following are OUT OF SCOPE:

Compromised end-user devices
Side-channel attacks on implementations
Social engineering of users

Mitigated Risks

The protocol design addresses the following threats:

Risk	Mitigation	Spec Reference
Replay attacks	Single-use nonces with 300s expiry	§ Nonce Generation
Signature forgery	Ed25519 signatures (cryptographically secure)	§ Key Generation
Nonce prediction	CSPRNG requirement, ≥128 bits entropy	§ Nonce Requirements
Session hijacking	HttpOnly, Secure cookies for PlanetaryCode	§ Successful Auth
Algorithm confusion	Explicit `"alg": "EdDSA"` check, rejection of others	§ Verification Steps

Residual Risks

Even with all mitigations applied, the following risks remain:

Lost private keys:: No recovery mechanism exists.
Compromised User Device:: If user device is compromised, attacker can sign as user. This is outside the threat model.
Poor randomness:: Relies on host system CSPRNG quality. Implementations should check for sufficient entropy.
Timing attacks:: Ed25519 is designed constant-time, but implementation flaws could leak information.
Rate-Limits exceeded:: Implementations SHOULD implement 429, implementations MAY send a HTTP Retry-After. Implementations are encouraged to look for rate limiting resources elsewhere as defining it is out of scope. the exact details of Rate-Limits are Planet-defined.