



Common Authentication Technology Next Generation            M. Sabadello
Internet-Draft                                          Danube Tech GmbH
Intended status: Standards Track                             31 May 2026
Expires: 2 December 2026


                    The DID-CHALLENGE SASL Mechanism
                 draft-sabadello-did-challenge-sasl-01

Abstract

   This specification defines "DID-CHALLENGE", a mechanism for the
   Simple Authentication and Security Layer (SASL) based on
   Decentralized Identifiers (DIDs).  The mechanism follows a server-
   first challenge/response pattern in which the client authenticates by
   producing a cryptographic signature over a server-generated
   challenge, using the private key associated with its DID.  Unlike
   password-based SASL mechanisms, no shared secret is transmitted or
   stored on the server; authentication is grounded entirely in
   asymmetric cryptography and the verifiable binding between a DID and
   its associated key material.

   An optional extension adds support for Verifiable Credentials (VCs)
   and Verifiable Presentations (VPs), enabling attribute-based access
   control in addition to identity authentication.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 2 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Sabadello                Expires 2 December 2026                [Page 1]

Internet-Draft             did-challenge-sasl                   May 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  SASL mechanism name . . . . . . . . . . . . . . . . . . . . .   4
   3.  Authentication  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  The Authentication Exchange . . . . . . . . . . . . . . .   4
     3.2.  Authorization Identity String . . . . . . . . . . . . . .   5
     3.3.  DID Challenge . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  DID Response  . . . . . . . . . . . . . . . . . . . . . .   6
     3.5.  Client Verification . . . . . . . . . . . . . . . . . . .   7
     3.6.  Server Verification . . . . . . . . . . . . . . . . . . .   7
   4.  SASL Exchange with DIDs . . . . . . . . . . . . . . . . . . .   8
   5.  (Optional) Authentication with VCs/VPs  . . . . . . . . . . .  11
     5.1.  The Authentication Exchange (with VC/VP support)  . . . .  11
     5.2.  VC-VP Challenge . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  VC-VP Response  . . . . . . . . . . . . . . . . . . . . .  11
     5.4.  Server Verification . . . . . . . . . . . . . . . . . . .  12
   6.  (Optional) SASL Exchange with DIDs and VCs/VPs  . . . . . . .  13
   7.  Example Exchange  . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Step 1: Client NameCallback for DID . . . . . . . . . . .  16
     7.2.  Step 2: Client JWKCallback for Private Key  . . . . . . .  16
     7.3.  Step 3: Server -> Client Challenge  . . . . . . . . . . .  17
     7.4.  Step 4: Client Signature  . . . . . . . . . . . . . . . .  17
     7.5.  Step 5: Client -> Server Response . . . . . . . . . . . .  17
     7.6.  Step 6: Server NameCallback with DID  . . . . . . . . . .  17
     7.7.  Step 7: Server Verification . . . . . . . . . . . . . . .  18
     7.8.  Step 8: Server AuthorizeCallback with authorization ID  .  18
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     8.1.  Mechanism Strength  . . . . . . . . . . . . . . . . . . .  18
     8.2.  Requirement for a Confidential Channel  . . . . . . . . .  19
     8.3.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  19
     8.4.  Man-in-the-Middle Attacks and Channel Binding . . . . . .  20
     8.5.  Server Spoofing and Mutual Authentication . . . . . . . .  20
     8.6.  Choosing and Trusting DID Resolvers . . . . . . . . . . .  21
     8.7.  Key Revocation, Rotation, and DID Method Properties . . .  21
     8.8.  Non-Repudiation . . . . . . . . . . . . . . . . . . . . .  22
     8.9.  Authentication vs. Authorization  . . . . . . . . . . . .  22
     8.10. Private Key Protection  . . . . . . . . . . . . . . . . .  22
     8.11. Security of the Optional VC/VP Extension  . . . . . . . .  23



Sabadello                Expires 2 December 2026                [Page 2]

Internet-Draft             did-challenge-sasl                   May 2026


     8.12. Denial of Service . . . . . . . . . . . . . . . . . . . .  23
   9.  Implementations . . . . . . . . . . . . . . . . . . . . . . .  24
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  25
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   Many Internet protocols require authentication.  Common approaches
   include username/password schemes (as used in IMAP or XMPP), static
   public key authentication (as used in SSH), and federated identity
   protocols (as used in OpenID Connect).  Each of these approaches has
   well-known limitations: passwords can be stolen or guessed, static
   public keys provide no mechanism for revocation, and federated
   schemes introduce a dependency on a central identity provider.

   Decentralized Identifiers (https://www.w3.org/TR/did-1.1/) are a
   class of globally unique identifier designed to be created and
   controlled directly by their subjects, without requiring a central
   registration authority.  A DID resolves to a DID Document - a
   machine-readable document that contains cryptographic key material
   and other metadata about the DID subject.  DID Documents are anchored
   in a Verifiable Data Registry: a system - such as a distributed
   ledger, decentralized file system, or DNS zone - that provides a
   trustworthy, tamper-evident record of DID state.  The controller of a
   DID can prove that control by signing data with the private key
   corresponding to a public key published in the DID Document, without
   needing permission from any third party.

   The Simple Authentication and Security Layer (https://www.rfc-
   editor.org/rfc/rfc4422.html) is an extensible framework that
   decouples authentication mechanisms from the application protocols
   that use them.  By defining a SASL mechanism, a new authentication
   approach can be made available to any SASL-enabled protocol -
   including IMAP, SMTP, LDAP, XMPP, and others - without modifying
   those protocols individually.

   This specification defines "DID-CHALLENGE", a SASL mechanism that
   allows a client to authenticate using a DID.  The SASL client takes
   the role of a DID controller; the SASL server takes the role of a DID
   Resolver and verifier.  Authentication proceeds by the server issuing
   a challenge (a nonce, timestamp, and realm), the client signing that
   challenge with its DID's private key, and the server verifying the
   signature against the public key material retrieved from the client's
   DID Document.  Because authentication is based on key ownership
   rather than a shared secret, a compromise of the server's credential
   store does not yield material that could be used to impersonate
   clients.




Sabadello                Expires 2 December 2026                [Page 3]

Internet-Draft             did-challenge-sasl                   May 2026


   This specification also defines an optional extension that adds
   support for Verifiable Credentials (VCs) and Verifiable Presentations
   (VPs).  VCs are signed statements issued by a trusted third party (an
   Issuer) about a subject - for example, attesting to a person's name,
   age, professional qualification, or membership in an organisation.
   After completing the initial DID-based authentication exchange, the
   server may issue one or more VC/VP Challenges requesting that the
   client present credentials of a specified type.  The client responds
   with a Verifiable Presentation: a signed envelope containing the
   requested credentials and binding them to the authenticated DID.
   This enables the server to make fine-grained, attribute-based access-
   control decisions beyond simple identity verification.

   Readers seeking to implement this mechanism should be familiar with
   the SASL framework (RFC4422 (https://www.rfc-editor.org/rfc/
   rfc4422.html)), the W3C DIDs v1.1 - DID Syntax
   (https://www.w3.org/TR/did-1.1/#did-syntax) specification, and the
   W3C DID Resolution v1.0 (https://www.w3.org/TR/did-resolution/)
   specification.  Familiarity with the W3C Verifiable Credentials Data
   Model v2.0 (https://www.w3.org/TR/2025/REC-vc-data-model-
   2.0-20250515/#types) specification is required for implementations
   that use the optional VC/VP extension.

2.  SASL mechanism name

   The name of the DID-based SASL mechanism is "DID-CHALLENGE".

3.  Authentication

   This section describes the interaction between a SASL client and SASL
   server that use the "DID-CHALLENGE" mechanism.

3.1.  The Authentication Exchange

   The "DID-CHALLENGE" mechanism is a server-first mechanism: the server
   sends the first piece of authentication data (see Section 3.3)
   without waiting for any initial client message beyond the mechanism
   selection.

   The exchange consists of the following steps:

   C: Request authentication exchange
   S: DID Challenge
   C: DID Response
   S: Outcome of authentication exchange






Sabadello                Expires 2 December 2026                [Page 4]

Internet-Draft             did-challenge-sasl                   May 2026


   The mechanism is capable of transferring an authorization identity
   string (see Section 3.2), which the client MUST include in the DID
   Response (see Section 3.4).

   The server is not expected to provide additional data when indicating
   a successful outcome.  On failure, the server MUST terminate the
   exchange and SHOULD provide an appropriate error indication to the
   client in accordance with the enclosing protocol's SASL profile.

   As security layers, the mechanism provides authentication and
   integrity protection of the authorization identity during the
   exchange, by means of a cryptographic signature over the server-
   generated challenge (see Section 3.2).  It does not provide a
   general-purpose security layer over the application data stream after
   authentication completes; confidentiality and integrity of post-
   authentication traffic MUST be provided by the underlying transport,
   such as (RFC8446 (https://www.rfc-editor.org/rfc/rfc8446.html)).

   The use of TLS is therefore strongly RECOMMENDED whenever this
   mechanism is employed (see Section 8.2).

3.2.  Authorization Identity String

   In the "DID-CHALLENGE" mechanism, the authorization identity string
   (https://www.rfc-editor.org/rfc/rfc4422#section-3.4.1) is a DID as
   defined by W3C DIDs v1.1 - DID Syntax (https://www.w3.org/TR/did-
   1.1/#did-syntax), and percent-encoded as defined by RFC3986 -
   Section 2.1 (https://www.rfc-editor.org/rfc/rfc3986#section-2.1).

   Example authorization identity string:

   did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D

3.3.  DID Challenge

   The DID Challenge has the following format:

   "<" nonce "." timestamp "@" realm ">"

   Where:

   *  nonce is a server-generated random string.  It MUST be unique
      across all challenges issued by the server.  The nonce MUST be
      generated by a cryptographically strong (pseudo) random number
      generator and MUST contain at least 64 bits of entropy.  The nonce
      MUST NOT contain the characters ".", "@", "<", ">", or SP, as
      these are used as delimiters in the challenge format.




Sabadello                Expires 2 December 2026                [Page 5]

Internet-Draft             did-challenge-sasl                   May 2026


   *  timestamp is the number of milliseconds elapsed since the Unix
      epoch (1970-01-01T00:00:00Z), encoded as a decimal integer with no
      leading zeros.  The server MUST set this field to the current time
      at the moment the challenge is generated.

   *  realm is the SASL realm of the server.  It identifies the service
      context to which the challenge belongs and is included in the
      signed material to prevent cross-service signature reuse.  The
      realm MUST NOT contain the characters "@", "<", ">", or SP.

   Example:

   <7795631894096664932.1765144656954@java-sasl-xmpp-server>

   In this example, the nonce is "7795631894096664932", the timestamp is
   "1741267200000" (2025-03-06T12:00:00Z in milliseconds), and the realm
   is "java-sasl-xmpp-server".

3.4.  DID Response

   The DID Response has the following format:

   did SP signature

   Where:

   *  did is the client's Decentralized Identifier (DID), percent-
      encoded as defined in Section 3.2.  This is the SASL authorization
      identity string supplied by the client.  The DID MUST be
      resolvable to a DID Document that contains at least one
      verification method with an "authentication" verification
      relationship (see W3C DIDs v1.1 - Verification Relationships
      (https://www.w3.org/TR/did-1.1/#verification-relationships).

   *  signature is the base64url encoding (RFC4648 (https://www.rfc-
      editor.org/rfc/rfc4648.html)) of the raw bytes of the digital
      signature, without padding characters ("=").  The signature MUST
      be computed over the entire DID Challenge string (including the
      enclosing angle brackets) as specified in Section 3.3.

   The signing algorithm MUST correspond to the key type of the
   verification method in the DID document (e.g., Ed25519 for keys of
   type "Multikey" with a Multibase-encoded Ed25519 public key).

   The two fields MUST be separated by exactly one space character.
   Leading and trailing whitespace in the DID Response MUST NOT be
   present.




Sabadello                Expires 2 December 2026                [Page 6]

Internet-Draft             did-challenge-sasl                   May 2026


   Example:

did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D frEko8nWU-rfArpMZsMVbXpg4xChaQIv_MCmIAmHD3OCWwYvL7CDOedMbezMs4pmGGuzpkRH2QX8UMa-RFToBg

3.5.  Client Verification

   Upon receiving the DID Challenge, the client MUST perform the
   verification steps listed below, in the order given.  If any step
   fails, the client MUST immediately treat the exchange as an
   authentication failure, MUST NOT proceed to subsequent steps, and
   MUST terminate the authentication exchange with an appropriate error
   indication.

   *  Parse the DID Challenge.  Verify that the DID Challenge conforms
      to the grammar defined in Section 3.3.  A challenge that does not
      conform MUST cause the client to abort the authentication
      exchange.

   *  Extract the nonce, timestamp, and signature fields.

   *  Verify the realm.  Verify that the realm in the received DID
      Challenge matches the realm of the service the client intends to
      authenticate to.  A realm mismatch MUST cause the client to abort
      the authentication exchange.

3.6.  Server Verification

   Upon receiving the DID Response, the server MUST perform the
   verification steps listed below, in the order given.  If any step
   fails, the server MUST immediately treat the exchange as an
   authentication failure, MUST NOT proceed to subsequent steps, and
   MUST terminate the authentication exchange with an appropriate error
   indication.

   *  Parse the DID Response.  Verify that the DID Response conforms to
      the grammar defined in Section 3.4.  A response that does not
      conform MUST cause the server to abort the authentication
      exchange.

   *  Extract the did and signature fields.

   *  Verify the nonce.  Verify that the nonce embedded in the DID
      Challenge has not previously been accepted in a completed
      authentication exchange.  The server MUST maintain a record of all
      nonces issued and accepted within the active timestamp window for
      this purpose.  A repeated nonce MUST be treated as a replay attack
      and the exchange rejected.




Sabadello                Expires 2 December 2026                [Page 7]

Internet-Draft             did-challenge-sasl                   May 2026


   *  Verify the timestamp.  Verify that the timestamp embedded in the
      DID Challenge, interpreted as milliseconds since the Unix epoch,
      represents a time within the server's acceptance window.  The
      RECOMMENDED acceptance window is no more than 300 seconds (5
      minutes) in the past, and no more than 5 seconds in the future (to
      accommodate minor clock skew between client and server).  Server
      clocks SHOULD be synchronized via NTP or an equivalent mechanism.
      A timestamp outside the acceptance window MUST be treated as an
      authentication failure.

   *  Resolve the DID.  Resolve the did field to a DID document using a
      trust valided DID resolver, in accordance with the W3C DID
      Resolution v1.0 (https://www.w3.org/TR/did-resolution/)
      specification.  If resolution fails for any reason, or if the DID
      is deactivated, the server MUST treat this as an authentication
      failure.

   *  Retrieve authentication verification methods.  From the resolved
      DID Document, retrieve all verification methods that have an
      "authentication" verification relationship, in accordance with the
      W3C DIDs v1.1 - Verification Relationships (https://www.w3.org/TR/
      did-1.1/#verification-relationships) specification.  If no such
      verification methods are present, the server MUST treat this as an
      authentication failure.

   *  Verify the signature.  Decode the signature field using base64url
      decoding without padding.  Using each candidate verification
      method retrieved in the previous step, attempt to verify the
      decoded signature against the entire DID Challenge string
      (including the enclosing angle brackets), treated as an opaque
      octet string.  The signing algorithm used for each attempt MUST
      correspond to the key type of the candidate verification method.
      If no verification method is able to verify the signature, the
      server MUST treat this as an authentication failure.

   If all steps succeed, the server MUST use the authenticated DID as
   the authorization identity.  The server MUST then invoke whatever
   authorization check is required by the enclosing application (e.g.,
   the AuthorizeCallback in the SASL framework) before granting access.

4.  SASL Exchange with DIDs

   This section illustrates the detailed steps of the SASL exchange.

   The flow includes the DID Challenge (see Section 3.3) and DID
   Response (see Section 3.4) steps.





Sabadello                Expires 2 December 2026                [Page 8]

Internet-Draft             did-challenge-sasl                   May 2026


                                                                          "The DID-CHALLENGE SASL mechanism"

                     ┌───────────────┐                  ┌───────────┐                             ┌───────────┐                         ┌───────────────┐          ┌────────────┐
                     │Protocol Client│                  │SASL Client│                             │SASL Server│                         │Protocol Server│          │DID Resolver│
                     └───────┬───────┘                  └─────┬─────┘                             └─────┬─────┘                         └───────┬───────┘          └─────┬──────┘
                             │                                │              Network Connection         │                                       │                        │
                             │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ >│                        │
                             │                                │                                         │                                       │                        │
                             │          Start login           │                                         │                                       │                        │
                             │───────────────────────────────>│                                         │                                       │                        │
                             │                                │                                         │                                       │                        │
                             │     NameCallback for DID       │                                         │                                       │                        │
                             │<───────────────────────────────│                                         │                                       │                        │
                             │                                │                                         │                                       │                        │
                             │              DID               │                                         │                                       │                        │
                             │───────────────────────────────>│                                         │                                       │                        │
                             │                                │                                         │                                       │                        │
                             │      ╔═══════════════════════╗ │                                         │                                       │                        │
                             │      ║did%3Akey%3A<..did..> ░║ │                                         │                                       │                        │
                             │      ╚═══════════════════════╝ │                                         │                                       │                        │
                             │JWKCallback for DID private key │                                         │                                       │                        │
                             │<───────────────────────────────│                                         │                                       │                        │
                             │                                │                                         │                                       │                        │
                             │        DID private key         │                                         │                                       │                        │
                             │───────────────────────────────>│                                         │                                       │                        │
                             │                                │                                         │                                       │                        │
  ╔══════════════════════════╧═══════════════════════════════╗│                                         │                                       │                        │
  ║{ "kty": "OKP", "crv": "Ed25519", "x": "..", "d": ".." } ░║│                                         │                                       │                        │
  ╚══════════════════════════╤═══════════════════════════════╝│                                         │                                       │                        │
                             │                                │       Start SASL authentication         │                                       │                        │
                             │                                │────────────────────────────────────────>│                                       │                        │
                             │                                │                                         │                                       │                        │
                             │                                │        List of authn mechanisms         │                                       │                        │
                             │                                │<────────────────────────────────────────│                                       │                        │
                             │                                │                                         │                                       │                        │
                             │                                │Selected authn mechanism "DID-CHALLENGE" │                                       │                        │
                             │                                │────────────────────────────────────────>│                                       │                        │
                             │                                │                                         │                                       │                        │
                             │                                │                                         ────┐                                   │                        │
                             │                                │                                             │ Generate DID Challenge            │                        │
                             │                                │                                         <───┘                                   │                        │
                             │                                │                                         │                                       │                        │
                             │            ╔═══════════════════╧═══════════════════════════════════════╗ │                                       │                        │
                             │            ║<1809528678543235072.1724868615672@java-sasl-xmpp-server> ░║ │                                       │                        │
                             │            ╚═══════════════════╤═══════════════════════════════════════╝ │                                       │                        │
                             │                                │DID Challenge (nonce, timestamp, realm)  │                                       │                        │
                             │                                │<────────────────────────────────────────│                                       │                        │
                             │                                │                                         │                                       │                        │



Sabadello                Expires 2 December 2026                [Page 9]

Internet-Draft             did-challenge-sasl                   May 2026


                             │                                ────┐                                     │                                       │                        │
                             │                                    │ Generate DID Response with signature│                                       │                        │
                             │                                <───┘                                     │                                       │                        │
                             │                                │                                         │                                       │                        │
                             │                                │ ╔═════════════════╗                     │                                       │                        │
                             │                                │ ║<..signature..> ░║                     │                                       │                        │
                             │                                │ ╚═════════════════╝                     │                                       │                        │
                             │                                │     DID Response (DID, signature)       │                                       │                        │
                             │                                │────────────────────────────────────────>│                                       │                        │
                             │                                │                                         │                                       │                        │
                             │                       ╔════════╧═══════════════════════════════════════╗ │                                       │                        │
                             │                       ║did%3Akey%3A<..did..> frEko8nWU<..signature..> ░║ │                                       │                        │
                             │                       ╚════════╤═══════════════════════════════════════╝ │                                       │                        │
                             │                                │                                         │                          Resolve DID  │                        │
                             │                                │                                         │───────────────────────────────────────────────────────────────>│
                             │                                │                                         │                                       │                        │
                             │                                │                                         │               DID document with DID public key                 │
                             │                                │                                         │<───────────────────────────────────────────────────────────────│
                             │                                │                                         │                                       │                        │
                             │                                │                                         ────┐                                   │                        │
                             │                                │                                             │ Verify DID Response with signature│                        │
                             │                                │                                         <───┘                                   │                        │
                             │                                │                                         │                                       │                        │
                             │                                │                                         │ ╔══════╗                              │                        │
                             │                                │                                         │ ║true ░║                              │                        │
                             │                                │                                         │ ╚══════╝                              │                        │
                             │                                │                                         │        NameCallback with DID          │                        │
                             │                                │                                         │──────────────────────────────────────>│                        │
                             │                                │                                         │                                       │                        │
                             │                                │                                         │               (empty)                 │                        │
                             │                                │                                         │<──────────────────────────────────────│                        │
                             │                                │                                         │                                       │                        │
                             │                                │                                         │          AuthorizeCallback            │                        │
                             │                                │                                         │──────────────────────────────────────>│                        │
                             │                                │                                         │                                       │                        │
                             │                                │                                         │       authorized=true with DID        │                        │
                             │                                │                                         │<──────────────────────────────────────│                        │
                             │                                │                                         │                                       │                        │
                             │                                │     Completed SASL authentication       │                                       │                        │
                             │                                │<────────────────────────────────────────│                                       │                        │
                     ┌───────┴───────┐                  ┌─────┴─────┐                             ┌─────┴─────┐                         ┌───────┴───────┐          ┌─────┴──────┐
                     │Protocol Client│                  │SASL Client│                             │SASL Server│                         │Protocol Server│          │DID Resolver│
                     └───────────────┘                  └───────────┘                             └───────────┘                         └───────────────┘          └────────────┘








Sabadello                Expires 2 December 2026               [Page 10]

Internet-Draft             did-challenge-sasl                   May 2026


5.  (Optional) Authentication with VCs/VPs

   This section defines an optional extension of the "DID-CHALLENGE"
   SASL mechanism which adds support for Verifiable Credentials (VCs)
   and Verifiable Presentations (VPs).

5.1.  The Authentication Exchange (with VC/VP support)

   The exchange consists of the following steps (expanding on
   Section 3):

   C: Request authentication exchange
   S: DID Challenge
   C: DID Response
   S: VC/VP Challenge
   C: VC/VP Response
   S: Outcome of authentication exchange

   The steps VC/VP Challenge and VC/VP Response may be repeated multiple
   times.

5.2.  VC-VP Challenge

   The VC/VP Challenge follows the following format:

   "<" nonce "." timestamp "." vc-type "@" realm ">"

   Where:

   *  For nonce, the same rules apply as in Section 3.3.

   *  For timestamp, the same rules apply as in Section 3.3.

   *  For realm, the same rules apply as in Section 3.3.

   *  vc-type MUST be a type of a Verifiable Credential as defined in
      W3C Verifiable Credentials Data Model v2.0 - Types
      (https://www.w3.org/TR/2025/REC-vc-data-model-
      2.0-20250515/#types).

   Example:

<7795631894096664932.1765144656954.DegreeCredential@java-sasl-xmpp-server>

5.3.  VC-VP Response

   The VC/VP Response follows the following format:




Sabadello                Expires 2 December 2026               [Page 11]

Internet-Draft             did-challenge-sasl                   May 2026


   vp

   Where:

   *  vp MUST be a Verifiable Presentation as defined in W3C Verifiable
      Credentials Data Model v2.0 - Verifiable Presentations
      (https://www.w3.org/TR/2025/REC-vc-data-model-2.0-
      20250515/#verifiable-presentations).

   Example:

   {
     "@context": [
       "https://www.w3.org/ns/credentials/v2",
       "https://www.w3.org/ns/credentials/examples/v2"
     ],
     "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
     "type": ["VerifiablePresentation"],
     "verifiableCredential": [{
       "id": "did:key:z6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D"
       "type": ["DegreeCredential"]
     }]
   }

5.4.  Server Verification

   Upon receiving the VC/VP Response, the server MUST perform the
   verification steps listed below, in the order given.  If any step
   fails, the server MUST immediately treat the exchange as an
   authentication failure, MUST NOT proceed to subsequent steps, and
   MUST terminate the authentication exchange with an appropriate error
   indication.

   *  Parse the VC-VP Response.  Verify that the VC-VP Response conforms
      to the grammar defined in Section 5.3.  A response that does not
      conform MUST cause the server to abort the authentication
      exchange.

   *  Verify the nonce and the timestamp following the same rules as in
      Section 3.6.

   *  Verify that the "holder" property of the VP field matches the did
      in Section 3.3.

   *  Verify that the "type" property of the VP field matches the
      requested vc-type field in the Section 5.3.





Sabadello                Expires 2 December 2026               [Page 12]

Internet-Draft             did-challenge-sasl                   May 2026


   *  Resolve the DID.  Resolve the "holder" property of the VP field to
      a DID document using a trust valided DID resolver, in accordance
      with the W3C DID Resolution v1.0 (https://www.w3.org/TR/did-
      resolution/) specification.  If resolution fails for any reason,
      or if the DID is deactivated, the server MUST treat this as an
      authentication failure.

   *  Retrieve assertion verification methods.  From the resolved DID
      Document, retrieve all verification methods that have an
      "assertionMethod" verification relationship, in accordance with
      the W3C DIDs v1.1 - Verification Relationships
      (https://www.w3.org/TR/did-1.1/#verification-relationships)
      specification.  If no such verification methods are present, the
      server MUST treat this as an authentication failure.

   *  Verify the signature.  Decode and verify the "proof" property of
      the VP field in accordance with the W3C Verifiable Credentials
      Data Model v2.0 (https://www.w3.org/TR/vc-data-model/)
      specification.  If the signature cannot be verified, the server
      MUST treat this as an authentication failure.

6.  (Optional) SASL Exchange with DIDs and VCs/VPs

   This section illustrates the detailed steps of the SASL exchange with
   DIDs and VCs/VPs, building on Section 4.

   The flow includes the DID Challenge (see Section 3.3), DID Response
   (see Section 3.4), VC/VP Challenge (see Section 5.2), and VC/VP
   Response (see Section 5.3).

                                                                             "The DID-CHALLENGE SASL mechanism with VCs"

                    ┌───────────────┐                        ┌───────────┐                                       ┌───────────┐                         ┌───────────────┐          ┌────────────┐
                    │Protocol Client│                        │SASL Client│                                       │SASL Server│                         │Protocol Server│          │DID Resolver│
                    └───────┬───────┘                        └─────┬─────┘                                       └─────┬─────┘                         └───────┬───────┘          └─────┬──────┘
                            │                                      │                Network Connection                 │                                       │                        │
                            │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ >│                        │
                            │                                      │                                                   │                                       │                        │
                            │             Start login              │                                                   │                                       │                        │
                            │─────────────────────────────────────>│                                                   │                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │        NameCallback for DID          │                                                   │                                       │                        │
                            │<─────────────────────────────────────│                                                   │                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │                 DID                  │                                                   │                                       │                        │
                            │─────────────────────────────────────>│                                                   │                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │            ╔═══════════════════════╗ │                                                   │                                       │                        │



Sabadello                Expires 2 December 2026               [Page 13]

Internet-Draft             did-challenge-sasl                   May 2026


                            │            ║did%3Akey%3A<..did..> ░║ │                                                   │                                       │                        │
                            │            ╚═══════════════════════╝ │                                                   │                                       │                        │
                            │   JWKCallback for DID private key    │                                                   │                                       │                        │
                            │<─────────────────────────────────────│                                                   │                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │           DID private key            │                                                   │                                       │                        │
                            │─────────────────────────────────────>│                                                   │                                       │                        │
                            │                                      │                                                   │                                       │                        │
      ╔═════════════════════╧════════════════════════════════════╗ │                                                   │                                       │                        │
      ║{ "kty": "OKP", "crv": "Ed25519", "x": "..", "d": ".." } ░║ │                                                   │                                       │                        │
      ╚═════════════════════╤════════════════════════════════════╝ │                                                   │                                       │                        │
                            │                                      │                                                   │                                       │                        │
          ╔══════╤══════════╪══════════════════════════════════════╪═══════════════╗                                   │                                       │                        │
          ║ OPT  │  Authentication with VCs/VPs                    │               ║                                   │                                       │                        │
          ╟──────┘          │                                      │               ║                                   │                                       │                        │
          ║                 │VCCallback for Verifiable Credentials │               ║                                   │                                       │                        │
          ║                 │<─────────────────────────────────────│               ║                                   │                                       │                        │
          ║                 │                                      │               ║                                   │                                       │                        │
          ║                 │       Verifiable Credentials         │               ║                                   │                                       │                        │
          ║                 │─────────────────────────────────────>│               ║                                   │                                       │                        │
          ║                 │                                      │               ║                                   │                                       │                        │
          ║                 │                  ╔═════════════════╗ │               ║                                   │                                       │                        │
          ║                 │                  ║{ ... VCs ... } ░║ │               ║                                   │                                       │                        │
          ╚═════════════════╪══════════════════╚═════════════════╝═╪═══════════════╝                                   │                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │            Start SASL authentication              │                                       │                        │
                            │                                      │──────────────────────────────────────────────────>│                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │             List of authn mechanisms              │                                       │                        │
                            │                                      │<──────────────────────────────────────────────────│                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │     Selected authn mechanism "DID-CHALLENGE"      │                                       │                        │
                            │                                      │──────────────────────────────────────────────────>│                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │                                                   ────┐                                   │                        │
                            │                                      │                                                       │ Generate DID Challenge            │                        │
                            │                                      │                                                   <───┘                                   │                        │
                            │                                      │                                                   │                                       │                        │
                            │                            ╔═════════╧═════════════════════════════════════════════════╗ │                                       │                        │
                            │                            ║<1809528678543235072.1724868615672@java-sasl-xmpp-server> ░║ │                                       │                        │
                            │                            ╚═════════╤═════════════════════════════════════════════════╝ │                                       │                        │
                            │                                      │     DID Challenge (nonce, timestamp, realm)       │                                       │                        │
                            │                                      │<──────────────────────────────────────────────────│                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      ────┐                                               │                                       │                        │
                            │                                          │ Generate DID Response with signature          │                                       │                        │
                            │                                      <───┘                                               │                                       │                        │
                            │                                      │                                                   │                                       │                        │



Sabadello                Expires 2 December 2026               [Page 14]

Internet-Draft             did-challenge-sasl                   May 2026


                            │                                      │ ╔═════════════════╗                               │                                       │                        │
                            │                                      │ ║<..signature..> ░║                               │                                       │                        │
                            │                                      │ ╚═════════════════╝                               │                                       │                        │
                            │                                      │          DID Response (DID, signature)            │                                       │                        │
                            │                                      │──────────────────────────────────────────────────>│                                       │                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │╔════════════════════════════════════════════════╗ │                                       │                        │
                            │                                      │║did%3Akey%3A<..did..> 2mJ4tBo6H<..signature..> ░║ │                                       │                        │
                            │                                      │╚════════════════════════════════════════════════╝ │                                       │                        │
                            │                                      │                                                   │                          Resolve DID  │                        │
                            │                                      │                                                   │───────────────────────────────────────────────────────────────>│
                            │                                      │                                                   │                                       │                        │
                            │                                      │                                                   │               DID document with DID public key                 │
                            │                                      │                                                   │<───────────────────────────────────────────────────────────────│
                            │                                      │                                                   │                                       │                        │
                            │                                      │                                                   ────┐                                   │                        │
                            │                                      │                                                       │ Verify DID Response with signature│                        │
                            │                                      │                                                   <───┘                                   │                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │                                                   │ ╔══════╗                              │                        │
                            │                                      │                                                   │ ║true ░║                              │                        │
                            │                                      │                                                   │ ╚══════╝                              │                        │
                            │                                      │                                                   │                                       │                        │
                            │    ╔══════╤══════════════════════════╪═══════════════════════════════════════════════════╪═══════════════════════════════════════╪═╗                      │
                            │    ║ OPT  │  Authentication with VCs/VPs                                                 │                                       │ ║                      │
                            │    ╟──────┘                          │                                                   │                                       │ ║                      │
                            │    ║                                 │                                                   ────┐                                   │ ║                      │
                            │    ║                                 │                                                       │ Generate VC/VP Challenge          │ ║                      │
                            │    ║                                 │                                                   <───┘                                   │ ║                      │
                            │    ║                                 │                                                   │                                       │ ║                      │
                            │    ║      ╔══════════════════════════╧═════════════════════════════════════════════════╗ │                                       │ ║                      │
                            │    ║      ║<1809528678543235072.1724868615672.DegreeCredential@java-sasl-xmpp-server> ░║ │                                       │ ║                      │
                            │    ║      ╚══════════════════════════╤═════════════════════════════════════════════════╝ │                                       │ ║                      │
                            │    ║                                 │VC/VP Challenge (nonce, timestamp, vc.type, realm) │                                       │ ║                      │
                            │    ║                                 │<──────────────────────────────────────────────────│                                       │ ║                      │
                            │    ║                                 │                                                   │                                       │ ║                      │
                            │    ║                                 ────┐                                               │                                       │ ║                      │
                            │    ║                                     │ Generate VC/VP Response with proof            │                                       │ ║                      │
                            │    ║                                 <───┘                                               │                                       │ ║                      │
                            │    ║                                 │                                                   │                                       │ ║                      │
                            │    ║                                 │ ╔══════════╗                                      │                                       │ ║                      │
                            │    ║                                 │ ║<..vp..> ░║                                      │                                       │ ║                      │
                            │    ║                                 │ ╚══════════╝                                      │                                       │ ║                      │
                            │    ║                                 │               VC/VP Response (VP)                 │                                       │ ║                      │
                            │    ║                                 │──────────────────────────────────────────────────>│                                       │ ║                      │
                            │    ║                                 │                                                   │                                       │ ║                      │
                            │    ║                                 │                                      ╔══════════╗ │                                       │ ║                      │
                            │    ║                                 │                                      ║<..vp..> ░║ │                                       │ ║                      │



Sabadello                Expires 2 December 2026               [Page 15]

Internet-Draft             did-challenge-sasl                   May 2026


                            │    ║                                 │                                      ╚══════════╝ │                                       │ ║                      │
                            │    ║                                 │                                                   ────┐                                   │ ║                      │
                            │    ║                                 │                                                       │ Verify VC/VP Response with proof  │ ║                      │
                            │    ║                                 │                                                   <───┘                                   │ ║                      │
                            │    ║                                 │                                                   │                                       │ ║                      │
                            │    ║                                 │                                                   │ ╔══════╗                              │ ║                      │
                            │    ║                                 │                                                   │ ║true ░║                              │ ║                      │
                            │    ╚═════════════════════════════════╪═══════════════════════════════════════════════════╪═╚══════╝══════════════════════════════╪═╝                      │
                            │                                      │                                                   │                                       │                        │
                            │                                      │                                                   │        NameCallback with DID          │                        │
                            │                                      │                                                   │──────────────────────────────────────>│                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │                                                   │               (empty)                 │                        │
                            │                                      │                                                   │<──────────────────────────────────────│                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │                                                   │          AuthorizeCallback            │                        │
                            │                                      │                                                   │──────────────────────────────────────>│                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │                                                   │       authorized=true with DID        │                        │
                            │                                      │                                                   │<──────────────────────────────────────│                        │
                            │                                      │                                                   │                                       │                        │
                            │                                      │          Completed SASL authentication            │                                       │                        │
                            │                                      │<──────────────────────────────────────────────────│                                       │                        │
                    ┌───────┴───────┐                        ┌─────┴─────┐                                       ┌─────┴─────┐                         ┌───────┴───────┐          ┌─────┴──────┐
                    │Protocol Client│                        │SASL Client│                                       │SASL Server│                         │Protocol Server│          │DID Resolver│
                    └───────────────┘                        └───────────┘                                       └───────────┘                         └───────────────┘          └────────────┘

7.  Example Exchange

7.1.  Step 1: Client NameCallback for DID

   When the client is initialized, it obtains a DID to be used for
   authentication.

-- CLIENT CALLBACK: NameCallback

>C Client DID:  --- defaultName: null, name: null
getName() -> did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D
C> DID:  --- defaultName: null, name: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D

7.2.  Step 2: Client JWKCallback for Private Key

   When the client is initialized, it obtains a private key that will be
   used for signing challenges.







Sabadello                Expires 2 December 2026               [Page 16]

Internet-Draft             did-challenge-sasl                   May 2026


-- CLIENT CALLBACK: JWKCallback

>C Client private key:  --- defaultText: (JWK), text: null
getTextInputJWK() -> {
    "kid": "did:key:z6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D#z6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D",
    "kty": "OKP",
    "crv": "Ed25519",
    "x": "EbV6-hVmDiD3DKTUgsf2SjjnO7t0ttwMhStQ5JyCFhw",
    "d": "vGjHIZzZxS3R4mo-V0I_S72ULXDqa2INqkAtuvqJUN8"
}
C> Private key:  --- defaultText: (JWK), text: {
  "kid": "did:key:z6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D#z6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D",
  "kty": "OKP",
  "crv": "Ed25519",
  "x": "EbV6-hVmDiD3DKTUgsf2SjjnO7t0ttwMhStQ5JyCFhw",
  "d": "vGjHIZzZxS3R4mo-V0I_S72ULXDqa2INqkAtuvqJUN8"
}

7.3.  Step 3: Server -> Client Challenge

   The server initiates the authentication flow by generating and
   sending a challenge.  The challenge contains a none, timestamp, and
   realm.

   -- SERVER -> CLIENT: Challenge
   <4513455346757278126.1757192932938@java-sasl-xmpp-server>

7.4.  Step 4: Client Signature

   The client signs the challenge using the DID's private key.

-- CLIENT
Created signature for challenge <4513455346757278126.1757192932938@java-sasl-xmpp-server>: frEko8nWU-rfArpMZsMVbXpg4xChaQIv_MCmIAmHD3OCWwYvL7CDOedMbezMs4pmGGuzpkRH2QX8UMa-RFToBg

7.5.  Step 5: Client -> Server Response

   The client response to the server with the DID and the signed
   challenge.

-- CLIENT -> SERVER: Response
did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D frEko8nWU-rfArpMZsMVbXpg4xChaQIv_MCmIAmHD3OCWwYvL7CDOedMbezMs4pmGGuzpkRH2QX8UMa-RFToBg

7.6.  Step 6: Server NameCallback with DID

   The server obtains the DID from the client's response.






Sabadello                Expires 2 December 2026               [Page 17]

Internet-Draft             did-challenge-sasl                   May 2026


-- SERVER CALLBACK: NameCallback

>S DID:  --- defaultName: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D, name: null
checkName(did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D) --> did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D
S> DID:  --- defaultName: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D, name: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D

7.7.  Step 7: Server Verification

   The server verifies the signature in the client's response by
   resolving the client's DID to a DID document, which contains public
   keys need for the verification.

-- SERVER
Verified signature frEko8nWU-rfArpMZsMVbXpg4xChaQIv_MCmIAmHD3OCWwYvL7CDOedMbezMs4pmGGuzpkRH2QX8UMa-RFToBg for challenge <4513455346757278126.1757192932938@java-sasl-xmpp-server>: true

7.8.  Step 8: Server AuthorizeCallback with authorization ID

   The server determines the DID as the "authorized ID", concluding the
   authentication flow.

-- SERVER CALLBACK: AuthorizeCallback

>S --- authenticationID: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D, authorizationID: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D, authorizedID: null, isAuthorized: false
S> --- authenticationID: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D, authorizationID: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D, authorizedID: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D, isAuthorized: true

authorizationId: did%3Akey%3Az6MkfePUhxLV6cM54cgZ4bGmnEdTNm3WDf4arwh5kR3dH51D

8.  Security Considerations

   This section addresses the security properties of the DID-CHALLENGE
   SASL mechanism and the threats it is, and is not, designed to
   counter.  Implementers SHOULD also consult the security
   considerations of the SASL framework (RFC4422 (https://www.rfc-
   editor.org/rfc/rfc4422.html)), the W3C Decentralized Identifiers v1.1
   (https://www.w3.org/TR/did-1.1/) specification, and, when the
   optional VC/VP extension is used, the W3C Verifiable Credentials Data
   Model 2.0 (https://www.w3.org/TR/2025/REC-vc-data-model-
   2.0-20250515/#types) specification.

8.1.  Mechanism Strength

   The DID-CHALLENGE mechanism authenticates clients by asymmetric
   cryptography rather than by transmitting a password or a password-
   derived value.  This eliminates an entire class of server-side risks
   present in password-based SASL mechanisms such as PLAIN or DIGEST-
   MD5: a compromise of the server's credential store yields no material
   that can be used to impersonate clients.




Sabadello                Expires 2 December 2026               [Page 18]

Internet-Draft             did-challenge-sasl                   May 2026


   The security of the mechanism depends on the following properties
   holding simultaneously: (a) the signature algorithm is
   computationally infeasible to forge; (b) the client's private key has
   not been compromised; (c) the DID resolver consulted by the server
   returns an authentic DID document (see Section 8.6; and (d) the
   authentication exchange is protected from observation and tampering
   by a lower-layer security protocol (see Section 8.2).  If any of
   these properties fails to hold, the security guarantees of the
   mechanism are reduced or eliminated entirely.

8.2.  Requirement for a Confidential Channel

   The DID-CHALLENGE mechanism does not itself provide a security layer
   (confidentiality or integrity protection of the application- layer
   data stream after authentication).  The client transmits its DID and
   a cryptographic signature in the clear at the SASL layer.  An
   eavesdropper learns the client's DID, which may be linkable to the
   client's real-world identity, and obtains a valid signature over a
   server-chosen challenge string.

   The DID-CHALLENGE mechanism MUST NOT be used over an unprotected
   channel.  Implementations MUST employ TLS (RFC8446 (https://www.rfc-
   editor.org/rfc/rfc8446.html)) or an equivalent protocol providing
   both confidentiality and integrity before initiating a DID-CHALLENGE
   exchange.

   When the optional VC/VP extension (see Section 5) is used, this
   requirement is especially critical.  Verifiable Presentations may
   contain sensitive personal attributes — such as name, date of birth,
   or professional credentials — that are transmitted in the clear at
   the SASL layer and MUST be protected by the underlying
   confidentiality layer.

8.3.  Replay Attacks

   The DID Challenge includes a nonce and a timestamp to prevent replay
   attacks.  The nonce MUST be generated by a cryptographically strong
   (pseudo) random number generator and MUST be unique per challenge.
   The server MUST maintain a record of all nonces issued within the
   active timestamp window and MUST reject any DID Response whose nonce
   has already been accepted.  A server that reuses nonces or fails to
   track them renders the replay defence ineffective.









Sabadello                Expires 2 December 2026               [Page 19]

Internet-Draft             did-challenge-sasl                   May 2026


   The timestamp provides a complementary time-bounded validity window.
   The server MUST reject any DID Response whose challenge timestamp
   lies outside a configured acceptance window, with a RECOMMENDED
   default of no more than 5 minutes.  Server clocks SHOULD be
   synchronized via NTP or an equivalent mechanism, since excessive
   clock skew will cause legitimate authentications to be rejected or,
   if compensated by widening the window, increase replay exposure.

   Both controls apply equally to the VC/VP Challenge and VC/VP Response
   defined in Section 5.  Servers MUST track VC/VP nonces independently
   and apply the same timestamp validation.

8.4.  Man-in-the-Middle Attacks and Channel Binding

   Because the client signs a server-supplied challenge, a man-in-the-
   middle adversary who can intercept and substitute the challenge could
   induce the client to produce a signature the adversary then uses to
   authenticate to the real server.  Running the exchange over TLS
   substantially raises the bar for this attack.  To eliminate it
   entirely, implementations SHOULD incorporate a TLS channel binding
   value (see RFC5929 (https://www.rfc-editor.org/rfc/rfc5929.html))
   into the signed material, so that a signature produced within one TLS
   session cannot be transferred to another.

   The realm field in the challenge binds the signature to a specific
   service context.  Clients MUST verify that the realm in the received
   challenge matches the service they intend to authenticate to before
   computing the DID Response, and MUST abort the exchange on a
   mismatch.

8.5.  Server Spoofing and Mutual Authentication

   The DID-CHALLENGE mechanism provides unilateral authentication: the
   client proves its identity to the server, but the server does not
   prove its identity to the client beyond what is provided by the
   underlying transport.  A malicious server can issue a legitimate-
   looking challenge and collect a valid DID Response.

   Clients MUST validate the server's TLS certificate against a trusted
   certification authority or equivalent trust anchor before initiating
   a DID-CHALLENGE exchange.  Clients MUST NOT proceed if certificate
   validation fails.  Deployments with stronger mutual- authentication
   requirements MAY combine DID-CHALLENGE with a DID- based server-
   authentication step at the application layer, though this is outside
   the scope of this specification.






Sabadello                Expires 2 December 2026               [Page 20]

Internet-Draft             did-challenge-sasl                   May 2026


8.6.  Choosing and Trusting DID Resolvers

   The server verifies the client's signature using public key material
   obtained by resolving the client's DID.  A malicious or compromised
   DID resolver that returns a fraudulent DID document could substitute
   attacker-controlled key material, allowing impersonation of an
   arbitrary DID.  As discussed in W3C DIDs v1.1 - Choosing DID
   Resolvers (https://www.w3.org/TR/did-1.1/#choosing-did-resolvers),
   there is no universal authority that mandates a correct resolver
   implementation for a given DID method; server implementers MUST
   select DID resolver software they have independently verified and
   trust.

   The network path between the server and its DID resolver SHOULD be
   protected by TLS.  Where the DID method supports it, the integrity of
   the retrieved DID document SHOULD be verified using content integrity
   mechanisms before its key material is used.  Servers SHOULD restrict
   the set of accepted DID methods to those whose resolver
   implementations and underlying registries have undergone independent
   security review.

8.7.  Key Revocation, Rotation, and DID Method Properties

   A DID controller who suspects key compromise SHOULD immediately
   update the DID document to revoke or rotate the affected verification
   method.  There is an inherent window of exposure between the moment
   of compromise and the moment the revocation propagates to the
   server's resolver; its duration depends on registry propagation speed
   and the server's cache refresh policy.  Servers MUST NOT rely
   indefinitely on cached DID documents, and SHOULD treat a DID
   resolution failure as an authentication failure rather than silently
   falling back to stale cached data.

   DID methods differ significantly in their security properties.
   Methods such as "did:key" encode the public key directly in the
   identifier and support neither revocation nor rotation; a compromised
   private key cannot be remediated and the DID must be abandoned
   entirely.  Methods anchored in distributed ledgers or similar
   registries support revocation but introduce availability and
   integrity dependencies on that infrastructure.  Methods based on DNS
   (such as "did:web") inherit the DNS attack surface, including
   susceptibility to hijacking.

   Servers SHOULD maintain an explicit list of accepted DID methods and
   SHOULD prefer those whose specifications have undergone independent
   security review, as required by W3C DIDs v1.1 - Security Requirements
   (https://www.w3.org/TR/did-1.1/#security-requirements).




Sabadello                Expires 2 December 2026               [Page 21]

Internet-Draft             did-challenge-sasl                   May 2026


8.8.  Non-Repudiation

   The DID Response is a cryptographic signature over a challenge that
   encodes a unique nonce, a timestamp, and the server's realm.
   Provided the client's private key is used exclusively by the DID
   controller and has not been compromised, this signature constitutes
   evidence that the DID controller authenticated to the specified
   server at approximately the time encoded in the challenge.  This
   property, discussed in W3C DIDs v1.1 - Non-Repudiation
   (https://www.w3.org/TR/did-1.1/#non-repudiation), supports non-
   repudiation of authentication events.  Deployments that require non-
   repudiation for compliance or forensic purposes SHOULD log and
   archive authentication exchanges accordingly.

8.9.  Authentication vs. Authorization

   Successful completion of the DID-CHALLENGE exchange proves that the
   client controls a private key corresponding to a verification method
   listed under the "authentication" relationship in its DID document.
   This proves control of the DID; it does not by itself confer any
   authorization to access resources on the server.  Servers MUST
   maintain and enforce an authorization policy that maps authenticated
   DIDs to permitted operations, independently of the authentication
   outcome.

8.10.  Private Key Protection

   The security of DID-CHALLENGE rests entirely on the secrecy of the
   client's private key.  An adversary who obtains the private key can
   authenticate as the corresponding DID until the DID document is
   updated to revoke the associated verification method — and, for DID
   methods that do not support revocation, indefinitely.

   Client implementations MUST protect private keys in a manner
   commensurate with the sensitivity of the resources being accessed.
   Suitable measures include hardware security modules (HSMs),
   operating-system-provided secure key storage, or encrypted software
   key stores protected by a strong passphrase.  Private keys MUST NOT
   be stored in plaintext.  Implementers MUST ensure that the
   JWKCallback interface does not expose the private key to unauthorized
   processes or log files.










Sabadello                Expires 2 December 2026               [Page 22]

Internet-Draft             did-challenge-sasl                   May 2026


8.11.  Security of the Optional VC/VP Extension

   When the optional VC/VP extension is used, the server MUST
   additionally verify: that the VP proof is valid and was produced
   using a key with an "assertionMethod" relationship in the client's
   DID document; that the VP "holder" property matches the authenticated
   DID; that each credential's issuer signature is valid; that no
   credential has expired or been revoked; and that the credential type
   matches the type requested in the VC/VP Challenge.

   Servers MUST implement credential status checking to detect revoked
   credentials, and MUST maintain an explicit issuer trust policy,
   rejecting credentials from issuers not covered by that policy.  The
   trustworthiness of a credential issuer cannot be inferred from the
   credential itself.  Finally, servers SHOULD request only the
   credential types strictly necessary for the access-control decision
   being made, to minimise unnecessary disclosure of personal
   information, particularly given that VPs are transmitted in the clear
   at the SASL layer (see Section 8.2).

8.12.  Denial of Service

   The DID-CHALLENGE mechanism introduces potential denial-of-service
   vectors that do not arise in password-based SASL mechanisms.
   Implementers SHOULD consider each of the following.

   Challenge generation and nonce tracking.  Each mechanism-selection
   message causes the server to generate a nonce and allocate an entry
   in its nonce-tracking table.  An attacker who sends many such
   messages can exhaust server memory and CPU.  Servers MUST enforce a
   short timeout on incomplete exchanges (RECOMMENDED: 30 seconds from
   challenge issuance), after which the nonce is discarded and any
   subsequent messages referencing it rejected.  Servers SHOULD rate-
   limit challenge issuance per source address and SHOULD bound the size
   of the nonce table.

   DID resolution amplification.  Every authentication attempt requires
   an outbound DID resolution request.  An attacker who sends many
   requests using different DIDs forces a corresponding number of
   outbound network requests, potentially stressing both the server and
   DID method infrastructure.  Servers SHOULD cache recently resolved
   DID Documents for a short period (subject to the constraints in
   Section 8.7), rate-limit outbound resolution requests, and impose a
   resolution timeout.

   Cryptographic verification cost.  Signature verification is
   computationally expensive, and the server may need to try multiple
   candidate keys if the DID Document contains more than one



Sabadello                Expires 2 December 2026               [Page 23]

Internet-Draft             did-challenge-sasl                   May 2026


   "authentication" verification method.  The ordering of steps in
   Section 3.6) is therefore deliberate: the cheap, non-cryptographic
   checks (format, nonce, timestamp) are placed first so that most
   malformed or replayed requests are rejected before any signature
   verification is attempted.  Servers MAY additionally impose per-
   source-address limits on signature verification attempts.

   VC/VP extension.  The optional VC/VP extension adds VP proof
   verification, per-credential issuer signature verification, and
   credential status checking to each exchange, all of which may involve
   further outbound network requests.  The same rate-limiting measures
   above apply.  Servers SHOULD additionally cap the number of
   credentials permitted in a single Verifiable Presentation and reject
   oversized presentations before performing any cryptographic work.
   Servers SHOULD cache credential status information briefly to avoid
   redundant outbound requests during bursts of authentication attempts.

9.  Implementations

   The following repositories contain various parts of an example
   implementation:

   *  SASL client demonstration components:
      https://github.com/peacekeeper/java-sasl-client-demo
      (https://github.com/peacekeeper/java-sasl-client-demo)

   *  SASL server demonstration components:
      https://github.com/peacekeeper/java-sasl-server-demo
      (https://github.com/peacekeeper/java-sasl-server-demo)

   *  SASL local "Hello World" demonstration:
      https://github.com/peacekeeper/java-sasl-local-demo
      (https://github.com/peacekeeper/java-sasl-local-demo)

   *  Implementation of a DID-based SASL authentication mechanism:
      https://github.com/peacekeeper/java-sasl-did-mechanism
      (https://github.com/peacekeeper/java-sasl-did-mechanism)

   *  XMPP server (based on Tigase) using the DID-based SASL
      authentication mechanism: https://github.com/peacekeeper/java-
      sasl-xmpp-server (https://github.com/peacekeeper/java-sasl-xmpp-
      server)

   *  XMPP client demo (based on Tigase) using the DID-based SASL
      authentication mechanism: https://github.com/peacekeeper/java-
      sasl-xmpp-client-tigase (https://github.com/peacekeeper/java-sasl-
      xmpp-client-tigase)




Sabadello                Expires 2 December 2026               [Page 24]

Internet-Draft             did-challenge-sasl                   May 2026


   *  XMPP client demo (based on Smack) using the DID-based SASL
      authentication mechanism: https://github.com/peacekeeper/java-
      sasl-xmpp-client-smack (https://github.com/peacekeeper/java-sasl-
      xmpp-client-smack)

   *  XMPP client plugin (based on Spark) using the DID-based SASL
      authentication mechanism: https://github.com/peacekeeper/java-
      sasl-xmpp-client-spark (https://github.com/peacekeeper/java-sasl-
      xmpp-client-spark)

   *  XMPP client application (based on Spark) using the DID-based SASL
      authentication mechanism: https://github.com/peacekeeper/java-
      sasl-xmpp-client-spark (https://github.com/peacekeeper/java-sasl-
      xmpp-client-spark)

10.  Acknowledgements

   The author would like to thank the members of the KITTEN working
   group for their review and feedback on earlier versions of this
   specification.

   This work was funded through NGI0 Commons Fund (https://nlnet.nl/
   commonsfund), a fund established by NLnet (https://nlnet.nl) with
   financial support from the European Commission's Next Generation
   Internet (https://ngi.eu) program.

   Learn more at the NLnet project page (https://nlnet.nl/project/DID-
   SASL).

Author's Address

   Markus Sabadello
   Danube Tech GmbH
   Margaretenstraße 70/1/7
   A-1050 Wien
   Austria
   Phone: +43-664-3154848
   Email: markus@danubetech.com













Sabadello                Expires 2 December 2026               [Page 25]
