Abstract

This specification defines a method for authenticating HTTP requests using Schnorr signatures, providing a decentralized and secure authentication mechanism. By leveraging Schnorr signatures, widely used in cryptocurrencies like Bitcoin and Litecoin, this method enables seamless integration with decentralized networks and services.

Status of This Document

This is a draft document of the W3C Nostr Community Group and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA).

Table of Contents

1. Introduction

1.1 Motivation

The rise of decentralized applications and services necessitates secure and user-centric authentication mechanisms. Traditional centralized authentication methods often introduce single points of failure and privacy concerns. By utilizing Schnorr signatures for HTTP authentication, we can achieve a decentralized, secure, and privacy-preserving authentication protocol suitable for modern web applications.

1.2 Background on Schnorr Signatures

Schnorr signatures are digital signature schemes known for their simplicity, efficiency, and provable security. They are extensively used in blockchain technologies such as Bitcoin and Litecoin. Their non-malleability and linearity properties make them ideal for complex cryptographic protocols.

1.3 Relation to Existing Standards

This specification builds upon the concepts introduced in RFC 7235 (HTTP/1.1 Authentication) and extends the authentication framework to support Schnorr signatures. It also aligns with efforts in decentralized networks like Nostr and projects like Solid that explore signature-based authentication.

2. Use Cases

2.1 Single Sign-On (SSO)

Enable users to authenticate across multiple services using a single cryptographic identity, eliminating the need for passwords and reducing friction in the user experience.

2.2 Decentralized Authentication

Facilitate authentication in decentralized applications where traditional centralized authentication methods are not viable, enhancing security and user control over personal data.

2.3 Integration with Blockchain Networks

Leverage existing cryptographic keys from blockchain networks like Bitcoin, allowing users to authenticate with services using the same keys that control their digital assets.

3. Terminology

Client

An entity that initiates an HTTP request requiring authentication.

Server

An entity that responds to the HTTP request and validates the authentication information.

Schnorr Signature

A cryptographic digital signature produced using the Schnorr signature scheme.

Event

A JSON object containing authentication data, signed by the client's private key.

4. Protocol Overview

The authentication protocol utilizes a signed JSON event included in the HTTP Authorization header. The event contains necessary information for the server to validate the request, including the request URL, HTTP method, and a timestamp.

4.1 Protocol Diagram

4.2 Event Structure

The event is a JSON object with the following fields:

• id: The hash of the serialized event.
• pubkey: The public key of the client in hexadecimal format.
• content: SHOULD be an empty string.
• kind: An integer value of 27235, referencing RFC 7235.
• created_at: A UNIX timestamp indicating when the event was created.
• tags: An array of tags providing additional information.
  • ["u", "<absolute-URL>"]: The absolute URL of the request.
  • ["method", "<HTTP-method>"]: The HTTP method used for the request.
  • ["payload", "<sha256-hex>"] (optional): SHA-256 hash of the request body for methods like POST, PUT, PATCH.
• sig: The Schnorr signature of the serialized event.

4.3 Authentication Flow

1. The client constructs the event with the required fields and signs it using their private key.
2. The client includes the base64-encoded event in the Authorization header with the scheme Schnorr.
3. The server receives the request and validates the event as per the Event Validation section.
4. Upon successful validation, the server processes the request; otherwise, it responds with 401 Unauthorized.

5. HTTP Authorization Header

The client MUST include the signed event in the Authorization header using the Schnorr scheme. The event MUST be base64-encoded.

5.1 Header Format

Authorization: Schnorr <base64-encoded-event>

5.2 Example

Authorization: Schnorr eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4MjQ0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1IiwiaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vcmVzb3VyY2UiXSxbIm1ldGhvZCIsIkdFVCJdXSwiY2FsbGJhY2siOm51bGwsInNpZyI6IjVlZDlkOGVjOTU4YmM4NTRmOTk3YmRjMjRhYzMzN2QwMDVhZjM3MjMyNDc0N2VmZTRhMDBlMjRmNGMzMDQzN2ZmNGRkODMwODY4NGJlZDQ2N2Q5ZDZiZTNlNWE1MTdiYjQzYjE3MzJjYzdkMzk0OWEzYWFmODY3MDVjMjIxODQifQ==

6. Event Validation

Servers MUST perform the following checks to validate the event:

1. Kind Check: The kind field MUST be 27235.
2. Timestamp Check: The created_at timestamp MUST be within a reasonable time window (e.g., ±60 seconds of the server's current time).
3. URL Match: The ["u", "<absolute-URL>"] tag MUST exactly match the absolute request URL, including query parameters.
4. Method Match: The ["method", "<HTTP-method>"] tag MUST match the HTTP method used for the request.
5. Signature Verification: The sig field MUST be a valid Schnorr signature of the serialized event, verifiable using the pubkey.
6. Payload Hash Check (optional): If the request includes a body and the event contains a ["payload", "<sha256-hex>"] tag, the SHA-256 hash of the request body MUST match the provided hash.

If any of these checks fail, the server SHOULD respond with 401 Unauthorized.

6.1 Additional Validation

Servers MAY perform additional implementation-specific validation checks, such as rate limiting or public key blacklisting.

7. Security Considerations

• Replay Attacks: The timestamp validation mitigates replay attacks by ensuring events are timely. Servers SHOULD enforce strict time windows.
• Man-in-the-Middle Attacks: It is RECOMMENDED to use HTTPS to prevent interception and tampering with the Authorization header.
• Key Management: Clients MUST securely store private keys. Compromise of a private key allows impersonation.
• Denial of Service: Servers SHOULD implement measures to mitigate DoS attacks, such as rate limiting authentication attempts.

8. Privacy Considerations

• Anonymity: Public keys serve as identifiers. Clients concerned with privacy MAY use different key pairs for different services.
• Data Minimization: The event SHOULD contain only the necessary information for authentication to minimize exposure of client data.

9. References

9.1 Normative References

[RFC7235]

Fielding, R., and Reschke, J., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. https://www.rfc-editor.org/rfc/rfc7235

9.2 Informative References

[Schnorr]

Wikipedia, "Schnorr Signature", https://en.wikipedia.org/wiki/Schnorr_signature

[Nostr]

Nostr Protocol, https://github.com/nostr-protocol

[Solid]

Solid Project, https://solidproject.org/

Acknowledgments

Special thanks to the members of the W3C Nostr Community Group and the broader community for their valuable feedback and contributions.