𝗧𝗵𝗶𝘀 𝗜𝘀 𝗔 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝗔𝗴𝗻𝗼𝘀𝘁𝗶𝗰 𝗚𝘂𝗶𝗱𝗲

𝗧𝗵𝗶𝘀 𝗜𝘀 𝗔 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲-𝗔𝗴𝗻𝗼𝘀𝘁𝗶𝗰 𝗚𝘂𝗶𝗱𝗲 To implement DBSC server-side, you need to know the wire contract. This includes:

• Which endpoints to expose
• The exact bytes in each header
• How to verify proofs
• The order of checks

You will implement two HTTP endpoints and one response header. This is the whole native protocol.

• POST /dbsc/registration: the browser sends its new public key here
• POST /dbsc/refresh: the browser re-proves key possession here
• A Secure-Session-Registration response header is attached to your login response

You also need a small amount of state: a session record and a short-lived challenge store. When the browser sends a request, it includes a Secure-Session-Response header with a JWS proof. You verify this proof using the algorithm allowlist and the stored key.

To verify a JWS proof:

• Check the algorithm is allowed (ES256 or RS256)
• Pick the key (from the header or stored)
• Verify the signature over the raw bytes
• Return the payload if the signature is valid

You need two stores: a session store and a challenge store. The challenge store must have an atomic consume operation to prevent replay attacks.

On POST /dbsc/registration:

• Verify the JWS proof
• Check the challenge exists and is not consumed or expired
• Store the bound key and update the session

On POST /dbsc/refresh:

• Verify the JWS proof
• Check the challenge exists and is not consumed or expired
• Update the session and set a fresh bound cookie

Remember to rate-limit the endpoints and use HTTPS with __Host- cookies. Source: https://dev.to/suliman_abdulrazzaq_14907/implementing-dbsc-server-side-a-language-agnostic-guide-152m