ANTRequest's FaviDiD Specification (Version 0.1.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.

danger! Deprecated! as of Wed Mar 11 2026. reason: vague and underspecific.

Table Of Contents

Status of this document

this document written on Tue Mar 10 2026 is Semantic version 0.1.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 uses external references

Examples of FaviDiD in use

link to examples, for now, there are none that fully implement this specification. should be an <ul> of links.

Definitions

Planet: A Server Implementing is called a Planet.
Edge: A Client Implementing is called an Edge. an edge is a client that interacts with the planet. could be a browser extension, the browser, or an app.
Implementation: A software instance of an Edge or Planet or both.
The Protocol: The Protocol as set forth in This Specification.
The Specification: The Specification is this htmlpage.
/Favicond_/: The Base Path of the protocol interactions. the underscore is a MUST. this path is directly after the domain.
REQUIRE: RFC2119's REQUIRED
Edge-Defined
Planet-Defined: A feature whose specific behavior is determined by the host environment rather than this specification. While this document may provide constraints, the Planet or Edge is free to define the exact behavior within those bounds.
Edge-Approximated
Planet-Approximated: A feature whose specific behavior is determined by the host environment rather than this specification. While this document may provide constraints, the Planet or Edge is free to define the exact behavior within those bounds, but preferably reacts like the recommending an ideal behavior.

Global Rules

All interactions MUST follow these global rules. If these rules are violated, the Implementation MUST abort the interaction and MAY notify the user (if any).

Applications MUST NOT connect to plain HTTP, Applications SHOULD try to change HTTP to HTTPS.
when a 404 or 500 is encountered Edges MUST read the Content-Type Header, if it states text/html the Edge SHOULD ignore the body and state the feature isnt supported to the user.
Info! on shared hosting 404 or 500 with a text/html mimetype is the default response for a file missing. when a file is missing the Planet cannot properly handle this interaction
Signature Verification MUST be done using the bytes As-Is (As Received), no Normalization, Canonicalization, Encoding change, or altering is allowed.
Info! This is important due to almost all algorithms assuming the bytes havent been altered at all. swapping the keys or changing indentation of a JSON or anything else will break the signature.
Normalization and Canonicalization is complex, and difficult. by Requiring no alteration, i can save a lot of difficulties for those that dont want to. You can Pretty Print it after you verified the thing.
Most Languages and Libraries come with JSON parsers, they do not come with JSON Canonicalization Engines. Most Languages and Libraries come with cryptographic functions that work on bytes. so by not allowing JSON Canonicalization at all, i can save a lot of difficulties for those that dont want to. and again, You can Pretty Print it after you verified the thing.

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

For Planets

As A Planet you need to have some endpoints open for standardized connection. This Specification does not make any REQUIREments about how you store your data, just that the data is delivered in these Formats.

When an Edge wants to sign up for your planet. you (reference to Your Planet) MUST

The Request Path MUST be /Favicond_/favidid/auth, abort these steps for any other Request Path with 400.
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.
REQUIRE the Edge to give you their FaviDiD (it is only their Public-Key, it is ok)
the Edge MUST sign the Nonce in a JWT described below.
You MUST check if the Nonce in their JWT Matches exactly as you gave it and that 300 seconds MUST NOT have passed.
if the Nonce matches create the user account, if it fails to match and that 300 seconds MUST NOT have passed, then fail the creation

On Finish

when those steps finish planets MUST return 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>"
}

Session Information and How the User Keeps their login is Planet-Defined. FaviDiD only replaces Passwords, it does not dictate anything else.

<Nonce> MUST be replaced with the actual Nonce used for verification above, exactly.

Incorrect Nonce. (error code: IncorrectNonce)

Invalid Signature. (error code: InvalidSignature)

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

{
    "proto": "FaviDiD-Auth",
    "success": false,
    "errorCode": "<errorCode>",
    "nonce": "<Nonce>"
}

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 interpret Retry-After: 15

<Nonce> MUST be replaced with the Planet Generated Nonce used for verification above, exactly.

<errorCode> MUST be replaced with the Failure Code described above.

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.

For Edges

The Request Path MUST be /Favicond_/favidid/auth

As An Edge you need to accept the Planet Nonces and sign them with that Private-Key of the user.

When You Receive a Planet Nonce from The User. you MUST create a JWT (compact JWS, 3 base64url parts) with the header being (indentation whitespace is Edge-Defined)

{
    "typ": "JWT",
    "alg": "EdDSA",
    "proto": "FaviDiD-Auth"
}

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.

the Edge MUST HTTP POST /Favicond_/favidid/auth with the Authorization, scheme MUST be FaviDiD value MUST be the JWT as described above.

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.
X25519 public keys MAY be converted to Ed25519 public keys. otherwise they MUST e Rejected.

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).

Example Usage (non-normative)

Here i describe the intended Authentication flow.

User visits a domain.
Domain supports "LogIn with FaviDiD"
User Clicks "LogIn with FaviDiD"
Website shows a random long string (for example Q0juNoxYOIGJwYzRTtWdWaA)
and says to sign it.
User copies the string and pastes it into their FaviDiD Authenticator app (the Edge).
Their FaviDiD Authenticator app does the following:
1. it takes the random long string converts it into
```
{"iss":"/*my FaviDiD*/","sub":"/*my FaviDiD*/","aud":"antrequest.nl","iat":1776006426,"nbf":1776006376,"exp":1776006726,"nonce":"Q0juNoxYOIGJwYzRTtWdWaA"}
```
  and converts it into base64url form eyJpc3MiOiIvKm15IEZhdmlEaUQqLyIsInN1YiI6Ii8qbXkgRmF2aURpRCovIiwiYXVkIjoiYW50cmVxdWVzdC5ubCIsImlhdCI6MTc3NjAwNjQyNiwibmJmIjoxNzc2MDA2Mzc2LCJleHAiOjE3NzYwMDY3MjYsIm5vbmNlIjoiUTBqdU5veFlPSUdKd1l6UlR0V2RXYUEifQ
  creating the JWT Payload.
2. it takes the following json
```
{"typ":"JWT","alg":"EdDSA","proto":"FaviDiD-Auth"}
```
  and converts it into base64url form eyJ0eXAiOiJKV1QiLCJhbGciOiJFZERTQSIsInByb3RvIjoiRmF2aURpRC1BdXRoIn0
  creating the JWT Header.
3. then it signs the two. TI2VZ9x9rKthZ9vJ0nhT1QbiBLxsAhps0I2Kamh8LRo
  creating the JWT Signature.
4. it gives the JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJFZERTQSIsInByb3RvIjoiRmF2aURpRC1BdXRoIn0.eyJpc3MiOiIvKm15IEZhdmlEaUQqLyIsInN1YiI6Ii8qbXkgRmF2aURpRCovIiwiYXVkIjoiYW50cmVxdWVzdC5ubCIsImlhdCI6MTc3NjAwNjQyNiwibmJmIjoxNzc2MDA2Mzc2LCJleHAiOjE3NzYwMDY3MjYsIm5vbmNlIjoiUTBqdU5veFlPSUdKd1l6UlR0V2RXYUEifQ.TI2VZ9x9rKthZ9vJ0nhT1QbiBLxsAhps0I2Kamh8LRo
  to the user.
Warning! this illustrative JWT is created using the wrong algorithms, but to people, it is all gibberish anyway.
The User puts the JWT in the Planet.
The Planet uses their Planet-Defined ways to create a session for the user.