NUT-15: Authentication with Schnorr Signatures

nut15.md

NUT-15: Authentication with Schnorr Signatures

==========================

optional use with: NUT-04, NUT-05

In this document, we describe a mechanism for obtaining time-bounded OAuth bearer tokens using Schnorr signatures for accessing protected endpoints for a mint. This specifically applies only for minting (NUT-04) and melting tokens (NUT-05). This NUT provides the mint with the ability to restrict who can mint and melt cashu tokens or, in some cases, implement temporary time-bound restrictions.

The registration process for authorizing public keys is outside the scope of this NUT and should be implemented separately by the mint. The mint should generate and store auth tokens based on the described authentican flow below. The auth tokens will be time bounded with an explict expiry time, after which the tokens should be destroyed by the mint.

NOTE: This NUT does not apply to swapping tokens (NUT-03) to preserve users' privacy and utilize spending conditions (NUT-10) to restrict swapping when required.

Authentication Flow

1. Client initiates authentication: The client application initiates the authentication process by redirecting the user to the designated authorization endpoint. This endpoint is provided by the mint.

Alice wants to access a protected resource on Bob's mint. Her client application initiates the authentication process by redirecting her to Bob's mint authorization endpoint:

GET https://bob.com/oauth/authorize/challenge?client_id=alice-app&scope=resource1

Bob's mint generates a random challenge in response, for example:

{
challenge : "f7d8c3b2a679e48d"
}

This challenge is displayed to Alice. Alice's client application then uses her private key to sign the challenge using Schnorr signature scheme. The resulting signature might look like this:

{
signature:"2c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef"
}

2. Signature verification and token issuance: Bob's mint verifies the validity of the Schnorr signature using alice's public key. If the signature is valid, Bob's mint issues a time-bounded OAuth bearer token to the client application. This token represents the user's identity and grants access to specific resources based on the scopes requested by the client.

Alice's client application submits the signature and public key to Bob's mint:

POST https://bob.com/v1/oauth/authorize

Post Data:

{
  client_id:alice-app 
  scope:resource1
  signature:c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef
  pubkey:7345786068584cd33000582ba87a9ddf77db5377c67910ab59d7e9a5f44
}

Response:

```json
HTTP/1.1 200 OK

{
"access_token": "9876543210fedcba",
"token_type": "Bearer",
"expires_in": 3600
}

3.Client accesses protected resources: The client application includes the bearer token in the Authorization header of subsequent requests to access protected resources. The mint validates the token and grants access if it is valid and has not expired.

Alice's client application can now access the protected resource on Bob's mint by including the bearer token in the Authorization header of the request:

POST https://bob.com/v1/mint/quote/bolt11

Authorization: Bearer 9876543210fedcba

Bob's mint validates the token and grants access to the resource if the token is valid and has not expired.

Schnorr Signature Details

• The Schnorr signature scheme is used due to its security properties and its compatibility with existing ecash infrastructure.
• The user's public key is assumed to be already registered with the mint. This registration process is outside the scope of this NUT.
• The challenge presented to the user should be sufficiently random to prevent replay attacks.
• The mint must verify the Schnorr signature using a trusted library or implementation.

Bearer Token Details

• The bearer token is a string representing the user's identity and access rights.
• The token is time-bounded with a specific expiry time. This expiry time should be chosen based on security considerations and the desired access duration.
• The token should be treated as a secret and protected from unauthorized access.

Benefits of Schnorr-based OAuth Authentication

• Enhanced security: Schnorr signatures provide strong cryptographic security for user authentication.
• Improved privacy: Schnorr signatures do not reveal the user's private key, protecting user privacy.
• utilizing existing infrastructure: Leverages existing mint infrastructure and Schnorr signature capabilities.
• Standardized approach: Aligns with the OAuth framework, ensuring compatibility with existing clients and services.

Implementation Considerations

• Secure storage of user private keys is crucial for the security of this authentication mechanism.
• The mint must implement robust signature verification and token management processes.
• Client applications must handle bearer tokens securely and respect their expiry times.
• If a mint choose to implement this NUT, then add this information to /info endpoint as per NUT-06 spec.

{
    "nuts": {
    "15": {
      "methods": [
        {
          "method": "/quote/bolt11",
          "restricted": true,     
        }
      ],
      "disabled": false
    },

}

This NUT provides a high-level overview of Schnorr-based OAuth authentication for the cashu protocol. Specific implementation details and security considerations should be further addressed during the development and deployment of this specification.