DID:WBA Method Specification | Web-Based Agent Decentralized Identifier

did:wba Method Specification (V0.1)

Abstract

The wba DID method is a Web-based decentralized identifier (DID) specification designed to meet the needs of cross-platform identity authentication and agent communication. This method extends and optimizes the did:web method, renamed as did:wba, retaining compatibility while enhancing adaptability for agent scenarios. In this specification, we design a process based on the did:wba method and HTTP protocol that allows a server to quickly verify the identity of clients from other platforms without increasing the number of interactions.

1. Introduction

1.1 Preamble

The wba DID method specification complies with the requirements specified in Decentralized Identifiers V1.0 [DID-CORE].

This specification builds upon the did:web method specification, adding DID document constraints, cross-platform identity authentication process, agent description service, and other specification descriptions, proposing a new method name did:wba (Web-Based Agent).

Considering that the did:web method specification is still a draft and may have future changes unsuitable for agent communication scenarios, and reaching consensus with the original authors on specification modifications is a long-term process, we have decided to use a new method name.

In the future, we do not rule out the possibility of merging the did:wba specification into the did:web specification, and we will work toward this goal.

The did:wba method references the did:web method specification at https://w3c-ccg.github.io/did-method-web, version dated July 31, 2024. For ease of management, we have backed up a copy of the did:web method specification document currently used by did:wba: did:web Method Specification.

1.2 Design Principles

When designing the did:wba method, our core principles were to fully leverage existing mature technologies and well-established Web infrastructure while achieving decentralization. Using did:wba, one can achieve characteristics similar to email, where each platform implements its own account system in a centralized way, while allowing interconnection between different platforms.

Additionally, various types of identifier systems can add support for DIDs, thereby building interoperable bridges between centralized, federated, and decentralized identifier systems. This means that existing centralized identifier systems do not need to be completely restructured; they only need to create DIDs on their foundation to achieve cross-system interoperability, greatly reducing the difficulty of technical implementation.

2. WBA DID Method Specification

2.1 Method Name

The name string used to identify this DID method is: wba. DIDs using this method MUST begin with the following prefix: did:wba. According to the DID specification, this string MUST be lowercase. The remainder of the DID (after the prefix) is specified below.

2.2 Method-Specific Identifier

The method-specific identifier is a fully qualified domain name protected by a TLS/SSL certificate, optionally including a path to the DID document. The formal rules describing valid domain name syntax are explained in (RFC1035), (RFC1123), and (RFC2181).

The method-specific identifier MUST match the common name used in the SSL/TLS certificate and MUST NOT contain an IP address. A port number may be included, but the colon MUST be percent-encoded to prevent conflicts with the path. Directories and subdirectories may be optionally included, using colons as separators instead of slashes.

wba-did = “did:wba:” domain-name wba-did = “did:wba:” domain-name * (":" path)

Example 3: wba method DID examples
did:wba:example.com

did:wba:example.com:user:alice

did:wba:example.com%3A3000

2.4 Key Material and Document Processing

Due to how most Web servers render content, a specific did:wba document will likely be served with the application/json media type. If a document named did.json is retrieved, the following processing rules should be followed:

  1. If @context exists at the root of the JSON document, the document should be processed according to JSON-LD rules. If it cannot be processed, or document processing fails, it should be rejected as a did:wba document.

  2. If @context exists at the root of the JSON document, is processed through JSON-LD, and includes the context https://www.w3.org/ns/did/v1, it can be further processed as a DID document according to [did-core specification section 6.3.2].

  3. If @context does not exist, it should be processed according to normal JSON rules for DID processing as specified in [did-core specification section 6.2.2].

  4. When a DID URL appears in a did:wba document, it MUST be an absolute URL.

Note: This includes URLs in embedded key material and other metadata, which prevents key confusion attacks.

2.5 DID Document Description

Beyond the DID Core specification, most other specifications are still in draft stage. This section will showcase a subset of a DID document used for authentication. To improve compatibility between systems, all fields marked as “must” must be supported by all systems; fields marked as “optional” can be selectively supported. Fields defined in other standards not listed here can be selectively supported.

DID Document Example:

{
    "@context": [
      "https://www.w3.org/ns/did/v1",
      "https://w3id.org/security/suites/jws-2020/v1",
      "https://w3id.org/security/suites/secp256k1-2019/v1",
      "https://w3id.org/security/suites/ed25519-2020/v1",
      "https://w3id.org/security/suites/x25519-2019/v1"
    ],
    "id": "did:wba:example.com%3A8800:user:alice",
    "verificationMethod": [
      {
        "id": "did:wba:example.com%3A8800:user:alice#WjKgJV7VRw3hmgU6--4v15c0Aewbcvat1BsRFTIqa5Q",
        "type": "EcdsaSecp256k1VerificationKey2019",
        "controller": "did:wba:example.com%3A8800:user:alice",
        "publicKeyJwk": {
          "crv": "secp256k1",
          "x": "NtngWpJUr-rlNNbs0u-Aa8e16OwSJu6UiFf0Rdo1oJ4",
          "y": "qN1jKupJlFsPFc1UkWinqljv4YE0mq_Ickwnjgasvmo",
          "kty": "EC",
          "kid": "WjKgJV7VRw3hmgU6--4v15c0Aewbcvat1BsRFTIqa5Q"
        }
      }
    ],
    "authentication": [
      "did:wba:example.com%3A8800:user:alice#WjKgJV7VRw3hmgU6--4v15c0Aewbcvat1BsRFTIqa5Q",
      {
        "id": "did:wba:example.com%3A8800:user:alice#key-1",
        "type": "Ed25519VerificationKey2020",
        "controller": "did:wba:example.com%3A8800:user:alice",
        "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
      }
    ],
    "keyAgreement": [
      {
        "id": "did:wba:example.com%3A8800:user:alice#key-2",
        "type": "X25519KeyAgreementKey2019", 
        "controller": "did:wba:example.com%3A8800:user:alice",
        "publicKeyMultibase": "z9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE"
      }
    ],
    "humanAuthorization": [
      "did:wba:example.com%3A8800:user:alice#WjKgJV7VRw3hmgU6--4v15c0Aewbcvat1BsRFTIqa5Q",
      {
        "id": "did:wba:example.com%3A8800:user:alice#key-3",
        "type": "Ed25519VerificationKey2020",
        "controller": "did:wba:example.com%3A8800:user:alice",
        "publicKeyMultibase": "z9XK2BVwLNv6gmMNbm4uVAjZpfkcJDwDwnZn6z3wweKLo"
      }
    ],
    "service": [
      {
        "id": "did:wba:example.com%3A8800:user:alice#ad",
        "type": "AgentDescription",
        "serviceEndpoint": "https://agent-network-protocol.com/agents/example/ad.json"
      }
    ]
}

Field Explanation:

  • @context: Required field, JSON-LD context defines the semantics and data model used in the DID document, ensuring document comprehensibility and interoperability. https://www.w3.org/ns/did/v1 is required. Others are added as needed.

  • id: Required field, cannot carry an IP address, but can carry a port, and when carrying a port, the colon needs to be encoded as %3A. Path segments are separated by colons.

  • verificationMethod: Required field, an array containing verification methods, defining public key information used to verify the DID subject.

    • Subfields:
      • id: Unique identifier for the verification method.
      • type: Type of verification method.
      • controller: The DID that controls this verification method.
      • publicKeyJwk: Public key information in JSON Web Key format.

  • authentication: Required field, lists verification methods used for authentication, can be strings or objects.

    • Subfields:
      • id: Unique identifier for the verification method.
      • type: Type of verification method.
      • controller: The DID that controls this verification method.
      • publicKeyMultibase: Public key information in Multibase format.

  • keyAgreement: Optional field, defines public key information used for key agreement, which can be used for encrypted communication between two DIDs. Verification methods generally use key agreement algorithms like X25519KeyAgreementKey2019 that can be used for key exchange.

    • Subfields:
      • id: Unique identifier for the key agreement method.
      • type: Type of key agreement method.
      • controller: The DID that controls this key agreement method.
      • publicKeyMultibase: Public key information in Multibase format.

  • humanAuthorization: Optional field, defines public key information used for human authorization, where the private key corresponding to this public key is only used when human authorization is required, used for important identity authentication scenarios.

    • Subfields:
      • id: Unique identifier for the human authorization method.
      • type: Type of human authorization method.
      • controller: The DID that controls this human authorization method.
      • publicKeyMultibase: Public key information in Multibase format.

  • service: Optional field, defines a list of services associated with the DID subject.

    • id: Unique identifier for the service.
    • type: Type of service. For agent description services, use “AgentDescription”.
    • serviceEndpoint: Service endpoint URL. For agent description services, this URL points to a document that follows the ANP-Agent Description Protocol Specification.

Note:

  1. Public key information currently supports two formats, publicKeyJwk and publicKeyMultibase. See https://www.w3.org/TR/did-extensions-properties/#verification-method-properties for details.
  2. Verification method types are defined at https://www.w3.org/TR/did-extensions-properties/#verification-method-types. Currently supported types include: EcdsaSecp256k1VerificationKey2019, Ed25519VerificationKey2018, X25519KeyAgreementKey2019. (Ed25519VerificationKey2020, JsonWebKey2020, etc. are not yet supported)
  3. AgentDescription is a new service type added to support discovery of agent description documents.

2.5 DID Method Operations

2.5.1 Create (Register)

The did:wba method specification does not specify concrete HTTP API operations but leaves programmatic registration and management to be defined by each implementer according to the requirements of their Web environment.

Creating a DID involves the following steps:

  1. Apply for a domain name with a domain registrar
  2. Store the location and IP address of the hosting service in a DNS lookup service
  3. Create a DID document JSON-LD file containing appropriate key pairs, and store the did.json file under a well-known URL to represent the entire domain name, or store it under a specified path if multiple DIDs need to be resolved under that domain name.

For example, for the domain name example.com, the did.json will be available at the following URL:

Example: Creating a DID
did:wba:example.com
 -> https://example.com/.well-known/did.json

If an optional path is specified instead of a bare domain name, the did.json will be available at the specified path:

Example 5: Creating a DID with an optional path
did:wba:example.com:user:alice
 -> https://example.com/user/alice/did.json

If an optional port is specified on the domain name, the colon between the host and port must be percent-encoded to prevent conflicts with the path.

Example 6: Creating a DID with an optional path and port
did:wba:example.com%3A3000:user:alice
 -> https://example.com:3000/user/alice/did.json

2.5.2 Read (Resolve)

The following steps must be performed to resolve a DID document from a Web DID:

  • Replace “:” in the method-specific identifier with “/” to obtain the fully qualified domain name and optional path.
  • If the domain name contains a port, percent-decode the colon.
  • Generate an HTTPS URL by prepending https:// to the expected DID document location.
  • If no path is specified in the URL, append /.well-known.
  • Append /did.json to complete the URL.
  • Perform an HTTP GET request to the URL using a proxy that can successfully negotiate a secure HTTPS connection, which enforces the security requirements described in Section 2.6 Security and Privacy Considerations.
  • Verify that the ID of the resolved DID document matches the Web DID being resolved.
  • When performing DNS resolution during the HTTP GET request, clients should use [RFC8484] to prevent tracking of the identity being resolved.

2.5.3 Update

To update a DID document, the did.json file corresponding to the DID needs to be updated. Note that the DID itself will remain unchanged, but the content of the DID document can change, for example, adding new verification keys or service endpoints.

Note: Using a version control system such as git and a continuous integration system such as GitHub Actions to manage updates to DID documents can provide support for authentication and audit history.

Note: HTTP API The update process does not specify a concrete HTTP API, but leaves programmatic registration and management to be defined by each implementer according to their needs.

2.5.4 Deactivate (Revoke)

To delete a DID document, the did.json file must be removed, or for other reasons made no longer publicly available.

2.6 Security and Privacy Considerations

Security and privacy considerations refer to [did:web Method Specification Section 2.6].

3. Cross-Platform Identity Authentication Based on did:wba Method and HTTP Protocol

When a client initiates a request to a server on a different platform, the client can authenticate the server using the domain name combined with TLS, and the server verifies the client’s identity based on the verification methods in the client’s DID document.

The client can include its DID and signature in the HTTP header during the first HTTP request. Without increasing the number of interactions, the server can quickly verify the client’s identity. After the first verification, the server can return an access token, and the client carries this token in subsequent requests. The server doesn’t need to verify the client’s identity each time but only needs to verify the access token.

Cross-Platform Identity Authentication Process

Figure 3: Cross-Platform Identity Authentication Process Based on did:wba

sequenceDiagram
    participant Agent A Client
    participant Agent B Server 
    participant Agent A DID Sever

    Note over Agent A Client,Agent B Server: First Request

    Agent A Client->>Agent B Server: HTTP Request: DID,Signature
    Agent B Server->>Agent A DID Sever: Get DID Document
    Agent A DID Sever->>Agent B Server: DID Document

    Note over Agent B Server: Authentication

    Agent B Server->>Agent A Client: HTTP Response: access token

    Note over Agent A Client, Agent B Server: Subsequent Requests

    Agent A Client->>Agent B Server: HTTP Request: access token
    Agent B Server->>Agent A Client: HTTP Response

3.1 Initial Request

When a client first initiates an HTTP request to a server, identity authentication should be performed according to the following method.

3.1.1 Request Header Format

The client sends the following information to the server via the Authorization header field:

  • DIDWba: Indicates using the did:wba method for authentication
  • did: The request contains the client’s DID identifier for authentication.
  • nonce: A randomly generated string used to prevent replay attacks. Must be unique for each request. A 16-byte random string is recommended.
  • timestamp: The time when the request was initiated, typically in ISO 8601 format UTC time, accurate to the second.
  • verification_method: Identifies the verification method used for signing in the request, which is the DID fragment of the verification method in the DID document. For example, with a verification method id “did:wba:example.com%3A8800:user:alice#key-1”, the DID fragment of the verification method is “key-1”.
  • signature: A signature of the nonce, timestamp, server domain name, and client DID. For ECDSA signatures, use the R|S format. Includes the following fields:
    • nonce: Randomly generated string
    • timestamp: Time when the request was initiated
    • service: Server domain name (note: the domain name does not include the port)
    • did: Client DID Client request example:
Authorization: DIDWba did="did:wba:example.com%3A8800:user:alice", nonce="abc123", timestamp="2024-12-05T12:34:56Z", verification_method="key-1", signature="base64url(signature_of_nonce_timestamp_service_did)"

3.1.2 Signature Generation Process

  1. The client generates a string containing the following information:
{ 
  "nonce": "abc123", 
  "timestamp": "2024-12-05T12:34:56Z", 
  "service": "example.com", 
  "did": "did:wba:example.com:user:alice" 
}

  1. Use JCS (JSON Canonicalization Scheme) to canonicalize the above JSON string, generating a canonicalized string.

  2. Use the SHA-256 algorithm to hash the canonicalized string, generating a hash value.

  3. Use the client’s private key to sign the hash value, generating a signature value signature, and perform URL-safe Base64 encoding.

  4. Construct the Authorization header in the above format and send it to the server.

3.2 Server Verification

3.2.1 Verify Request Header

After receiving the client request, the server performs the following verifications:

  1. Verify timestamp: Check if the timestamp in the request is within a reasonable time range, recommended time range is 1 minute. If the request timestamp is out of range, consider the request expired, return 401 Unauthorized, and attach challenge information.

  2. Verify nonce: Check if the nonce in the request has already been used or does not exist. If the nonce already exists, consider it a replay attack, return 401 Unauthorized, and attach challenge information.

  3. Verify DID permissions: Verify if the DID in the request has permission to access the server’s resources. If not, return 403 Forbidden.

  4. Verify signature:

  • Read the DID document based on the client’s DID.
  • Find the corresponding verification method in the DID document based on the verification_method in the request.
  • Use the public key in the verification method to verify the signature in the request.
  1. Verification result: If the signature verification succeeds, the request passes verification; otherwise, return 401 Unauthorized and attach challenge information.

3.2.2 Signature Verification Process

  1. Extract information: Extract nonce, timestamp, service, did, verification_method, and signature from the Authorization header.

  2. Construct verification string: Construct the same JSON string as the client using the extracted information:

{ 
    "nonce": "abc123", 
    "timestamp": "2024-12-05T12:34:56Z", 
    "service": "example.com", 
    "did": "did:wba:example.com:user:alice" 
}

  1. Canonicalize string: Use JCS (JSON Canonicalization Scheme) to canonicalize the JSON string, generating a canonicalized string.

  2. Generate hash value: Use the SHA-256 algorithm to hash the canonicalized string, generating a hash value.

  3. Get public key: Get the corresponding public key from the DID document based on did and verification_method.

  4. Verify signature: Use the obtained public key to verify the signature, ensuring that the signature was generated by the corresponding private key.

3.2.3 Return Access Token After Successful Authentication

After successful verification, the server can return an access token in the response. The access token is recommended to use the JWT (JSON Web Token) format. The client carries the access token in subsequent requests, and the server only needs to verify the access token instead of verifying the client’s identity each time. The following generation process is not required by the specification, but is provided for reference, implementers can define and implement their own as needed.

JWT generation method refers to RFC7519.

  1. Generate Access Token

Assuming the server uses JWT (JSON Web Token) as the Access Token format, a JWT typically contains the following fields:

  • header: Specifies the signing algorithm
  • payload: Stores user-related information
  • signature: Signs the header and payload to ensure integrity

The payload can include the following fields (other fields can be added as needed):

{
  "sub": "did:wba:example.com:user:alice",  // User DID 
  "iat": "2024-12-05T12:34:56Z",            // Issued at time
  "exp": "2024-12-06T12:34:56Z",            // Expiration time
}

Implementers can add other security measures to the payload as needed, such as using scope, binding IP addresses, etc.

  1. Return Access Token Concatenate the generated header, payload, and signature through URL-safe Base64 encoding to form the final Access Token. Then return it to the client via the Authorization header:
Authorization: Bearer <access_token>
  1. Client Sends Access Token The client sends the Access Token to the server via the Authorization header field in subsequent requests:
Authorization: Bearer <access_token>
  1. Server Verifies Access Token After receiving the client request, the server extracts the Access Token from the Authorization header and verifies it, including verifying the signature, verifying the expiration time, verifying fields in the payload, etc. Verification methods refer to RFC7519.

3.2.4 Error Handling

3.2.4.1 401 Response

When the server fails to verify the signature and requires the client to initiate the request again, it can return a 401 response.

Additionally, if the server does not support recording the client request’s Nonce, or requires the client to use a server-generated Nonce for signing each time, then a 401 response can be returned with challenge information including the Nonce for each initial client request. However, this increases the number of client requests, and implementers can choose whether to use this approach.

Error information is returned via the WWW-Authenticate header field, for example:

WWW-Authenticate: Bearer error="invalid_nonce", error_description="Nonce has already been used. Please provide a new nonce.", nonce="xyz987"

Includes the following fields:

  • error: Required field, error type, including the following string values:
    • invalid_request: Request format error, missing required fields, or contains unsupported parameters.
    • invalid_nonce: Nonce has been used or does not exist.
    • invalid_timestamp: Timestamp is out of range.
    • invalid_did: DID format error, or unable to find the corresponding DID document based on the DID.
    • invalid_signature: Signature verification failed.
    • invalid_verification_method: Unable to find the corresponding public key based on the verification method.
    • invalid_access_token: Access token verification failed.
    • forbidden_did: DID does not have permission to access the server’s resources.
  • error_description: Optional field, error description.
  • nonce: Optional field, server-generated random string. If included, the client needs to use this Nonce to regenerate the signature and reinitiate the request.

After receiving a 401 response, if the response includes a Nonce, the client needs to use the server’s Nonce to regenerate the signature and reinitiate the request. If the response does not include a Nonce, the client needs to use a client-generated Nonce to regenerate the signature and reinitiate the request.

Note that both the client and server need to limit the number of retries in their respective implementations to prevent entering an infinite loop.

3.2.4.2 403 Response

When the server successfully authenticates the identity but the DID does not have permission to access the server’s resources, it can return a 403 response.

4. Cross-Platform Identity Authentication Process Based on did:wba Method and JSON Format Data

In the previous chapter, we introduced a cross-platform identity authentication process based on the did:wba method and HTTP protocol. However, using the did:wba method for identity authentication is transport protocol agnostic. Here, we have established a cross-platform identity authentication process based on the did:wba method and JSON format data, which can be used in scenarios where JSON format is used for communication. This specification only describes the process of using JSON for identity authentication; how to transmit JSON is up to the implementer to decide.

Theoretically, protocols based on other data formats can also add support for the did:wba method.

The overall process is as follows:

sequenceDiagram
    participant Agent A Client
    participant Agent B Server 
    participant Agent A DID Sever

    Note over Agent A Client,Agent B Server: Initial Request

    Agent A Client->>Agent B Server: Authentication Request Info: DID,Signature
    Agent B Server->>Agent A DID Sever: Get DID Document
    Agent A DID Sever->>Agent B Server: DID Document

    Note over Agent B Server: Authentication

    Agent B Server->>Agent A Client: Authentication Response Info: access token

    Note over Agent A Client, Agent B Server: Subsequent Requests

    Agent A Client->>Agent B Server: Request: access token
    Agent B Server->>Agent A Client: Response

4.1 Initial Request

When a client first initiates a request to a server, identity authentication should be performed according to the following method.

4.1.1 Authentication Information Data Format

The client needs to send the following information to the server:

  • did: The request contains the client’s DID identifier for authentication.
  • nonce: A randomly generated string used to prevent replay attacks. Must be unique for each request. A 16-byte random string is recommended.
  • timestamp: The time when the request was initiated, typically in ISO 8601 format UTC time, accurate to the second.
  • verification_method: Identifies the verification method used for signing in the request, which is the DID fragment of the verification method in the DID document. For example, with a verification method id “did:wba:example.com%3A8800:user:alice#key-1”, the DID fragment of the verification method is “key-1”.
  • signature: A signature of the nonce, timestamp, server domain name, and client DID. For ECDSA signatures, use the R|S format. Includes the following fields:
    • nonce
    • timestamp
    • service (domain name of the service)
    • did (client DID)

Client request example:

{
  "did": "did:wba:example.com%3A8800:user:alice",
  "nonce": "abc123",
  "timestamp": "2024-12-05T12:34:56Z",
  "verification_method": "key-1",
  "signature": "base64url(signature_of_nonce_timestamp_service_did)"
}

Authentication information can be sent in a separate request or together with business request data.

4.1.2 Signature Generation Process

Same as 3.1.2 Signature Generation Process.

4.2 Server Verification

4.2.1 Verify Authentication Request

Verification process is the same as 3.2.1 Verify Request Header. The difference is that the did, nonce, timestamp, verificationMethod, and signature fields need to be extracted from the request data.

After verification passes, the server can return an access token, and the client carries this access token in subsequent requests. The server doesn’t need to verify the client’s identity each time but only needs to verify the access token.

The access token generation method is the same as 3.2.3 Return Access Token After Successful Authentication.

JSON response example:

{
  "code": 200,
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
}

Field description:

  • code: Status code, using HTTP status codes.
  • access_token: Access token returned after successful authentication.

After receiving a 200 response, the client can carry the access token for subsequent requests.

Subsequent request example:

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
}

4.2.2 Error Handling

Error handling is the same as 3.2.4 Error Handling.

JSON format 401 response example:

{
  "code": 401,
  "error": "invalid_nonce",
  "error_description": "Nonce has already been used. Please provide a new nonce.",
  "nonce": "1234567890"
}

JSON format 403 response example:

{
  "code": 403,
  "error": "forbidden_did",
  "error_description": "did not have permission to access the resource."
}

5 Distinguishing Human Authorization from Agent Automatic Authorization

For less important requests, user agents can authorize automatically. For example, when accessing a hotel agent and reading hotel information, human manual confirmation is not required, and the user agent can initiate the request on behalf of the human.

For important requests, such as booking a hotel room, the hotel agent may require human manual confirmation. When the user agent initiates a booking request, it needs to sign using the method defined in humanAuthorization. In this case, the user agent needs to initiate an authorization request to the human, asking for manual confirmation, and then proceed with the booking request.

The signing method is the same as 3.1 Initial Request.

User agent developers need to securely store the humanAuthorization private key and implement permission isolation. For example, using the humanAuthorization for signing only after verifying the user through biometric means (fingerprint, facial recognition, etc.).

Agents can define authorization types for documents or interfaces in their agent description documents. By default, all ordinary authorizations are sufficient. If a request requires human manual authorization, it needs to be explicitly defined in the document (see the Agent Description Specification for definition methods).

6 Privacy Protection Strategy

Privacy protection is very important in decentralized networks. For example, illegal software might record and track user behavior through the user’s DID, causing user privacy leakage.

For this, we recommend that DID providers adopt a multi-DID strategy, generating multiple DIDs for one user, each with different roles and permissions, using different key pairs, thus achieving privacy protection and fine-grained permission control.

For example, generate a main DID for the user, which generally remains unchanged, used for maintaining social relationships and similar scenarios. Then generate a series of sub-DIDs, which can be used for shopping, food delivery orders, ticket booking, and other scenarios. These sub-DIDs belong to the main DID, and can periodically deactivate expired DIDs and apply for new DIDs, improving privacy security protection.

7 Security Recommendations

Implementers need to consider the following security aspects when implementing:

  1. Key Management
  • The private key corresponding to the DID MUST be properly safeguarded and absolutely must not be leaked. Additionally, a mechanism for periodically refreshing private keys SHOULD be established.
  • Users SHOULD generate multiple DIDs, each with different roles and permissions, using different key pairs, implementing fine-grained permission control.
  1. Anti-Attack Measures
  • The server MUST record the Nonce in requests to prevent replay attacks.
  • The server MUST check the timestamp in requests to prevent time rollback attacks. Generally, the server’s nonce cache duration SHOULD be longer than the timestamp expiration duration.
  • When generating Nonces, MUST use secure random number generators provided by the operating system, complying with modern cryptographic security specifications and standards. For example, modules like Python’s secrets can be used to generate secure random numbers.
  1. Transport Security
  • The server SHOULD use the DNS-over-HTTPS (DoH) protocol when obtaining DID documents to enhance security.
  • The transport protocol MUST use HTTPS, and the client MUST strictly verify whether the other party’s CA certificate is trustworthy.
  1. Token Security
  • The client and server MUST properly safeguard Access Tokens and MUST set reasonable expiration times.
  • Additional security information SHOULD be included in Access Tokens, such as client IP binding, User-Agent binding, etc., to prevent Access Token misuse.

8. Use Cases

  1. Use Case 1: User Accessing Files on Other Websites Through an Intelligent Assistant

Alice has stored a file on the example.com website, and later she wants to access the file through an intelligent assistant. To do this, Alice first creates a DID based on the did:wba method on the intelligent assistant, logs into example.com, associates this DID with her account, and grants the DID permission to access the files. After completing the setup, the intelligent assistant can log into example.com using the DID, and after authentication, example.com allows the intelligent assistant to access the files stored by Alice. This DID can also be configured on other websites to allow the intelligent assistant to access files on different platforms.

  1. Use Case 2: User Calling APIs of Other Platform Services Through an Intelligent Assistant

Alice wants to call an API of a third-party service named example through an intelligent assistant. First, Alice creates a DID based on the did:wba method on the intelligent assistant and uses this DID to order relevant services on the example platform. The example service authenticates through the DID, confirms that the purchaser is Alice, and records her DID. After authentication, Alice can call the API of the example service through the intelligent assistant using the DID.

The current use case does not illustrate client authentication of the server, although this process can also work.

9. Summary

This specification builds upon the did:web method specification, adding DID document constraints, cross-platform identity authentication process, agent description service, and other specification descriptions, proposing a new method name did:wba (Web-Based Agent). It designs a cross-platform identity authentication process based on the did:wba method and HTTP protocol, providing detailed implementation methods.

The did:wba method will be further improved in the future, adding agent capability and protocol description service endpoints, bidirectional authentication processes between agents, and more.