ANTRequest's FaviDiD Specification (Version 0.2.0)

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 Wed Mar 11 2026 is Semantic version 0.2.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.1.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-2 MUST be present for this specification.
1. Generate a Nonce and keep it for 300 Seconds. how you create the Nonce is Planet-Approximated but MUST be within the base58 alphabet. Nonce SHOULD 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. 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.
Perform either one the following
successful authentication.
planets MUST respond with Status Code 200 Content-Type: application/json and a Body with At Least the following Keys.
```
{
    "proto": "FaviDiD-Auth",
    "success": true,
    "nonce": "<Nonce>",
    "PlanetaryCode": "<PlanetaryCode>",
    "PlanetaryCode-ExpiresAt": "<PlanetaryCode-ExpiresAt>"
}
```
<Nonce> MUST be replaced with the actual Nonce used for verification above, exactly.
<PlanetaryCode> MUST be replaced with a session token. the Planetary Code MAY be kept for as long as the session is valid and hasnt expired yet.
<PlanetaryCode-ExpiresAt> MUST be set to when <PlanetaryCode> expires, in the form of HTTP DATE. when it expires is Planet-Defined.
Incorrect Nonce. (error code: IncorrectNonce)
Invalid Signature. (error code: InvalidSignature)
Invalid Ed25519 Public Key. (error code: InvalidEdPublicKey)
Invalid Syntax. (error code: InvalidSyntax)
Unsupported Signature. (error code: UnsupportedSignature)
Unsupported Ed25519 Public Key. (error code: UnsupportedEdPublicKey)
Unsupported Syntax. (error code: UnsupportedSyntax)
planets MUST respond with Status Code 401 Content-Type: application/json
```
{
    "proto": "FaviDiD-Auth",
    "success": false,
    "errorCode": "<errorCode>"
}
```
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
Info! Retry-After SHOULD be included on 401 responses caused by nonce/signature failure, indicating when the client MAY retry with a new nonce request.

<Nonce> MUST be replaced with the Planet Generated Nonce used for verification above, exactly.
<errorCode> SHOULD be replaced with the Failure Code described above, if not wanted MUST be GenericError.
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="TVpeqriJkhm5mKv1dKCA9BD"
FaviDiD0-72 Realm="My Other Realm" Nonce="Gak9QsoHZnYKH63C5PruBvs"
FaviDiD35 Realm="antRequest.nl" Nonce="2NjJfsBRa6QENCAmVSjYTs6X"
FaviDiD1 Nonce="2VMcxu85YRjj1MhyvJqMjo5X" Realm="index.php"

invalid ones include

FaviDiD0-2 Nonce="dtwkrVFNG8V9y9s3qbnE3jk" (omits Realm)
FaviDiD0-2 Realm="My Other Realm" (omits Nonce)
FaviDiD1.3 Nonce="92Vkf8RwzWyuxx5dSHadH8Q" Realm="index.php" (uses dot instead of minus)
FaviDiD.3 Nonce="ysbpKm6VL6guSmdE86EVv9S" 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).