This document defines an authentication suite for the Linked Web Storage (LWS) protocol, enabling clients that are able to sign their own identity tokens to integrate with LWS.

This is an unofficial proposal.

Introduction

Self-issued identity is important for cases where applications act on their own behalf. This includes autonomous bots as well as server-side scripts, among others. In these cases, the agent is able to securely manage the private portion of a keypair, which it uses to generate signed JSON Web Tokens (JWT). This specification describes how this class of agents can generate authentication credentials that can be used with a Linked Web Storage while using agent identifiers with the `did:key:` method.

Terminology

The terms "authorization server" and "client" are defined by The OAuth 2.0 Authorization Framework [[!RFC6749]].

The terms "JSON Web Token (JWT)" and "claim" are defined by JSON Web Token [[!RFC7519]].

The terms "agent", "authentication credential", and "authentication suite" are defined by Linked Web Storage Protocol [[!LWS10-CORE]]

Authentication Credential Serialization

A self-issued authentication credential is serialized as a signed JSON Web Token (JWT). In order to use a JWT as an LWS authentication credential, the following additional requirements apply.

An example JWT that is also an LWS authentication credential is included below.

{
  "kty": "EC",
  "alg": "ES256",
  "typ": "JWT",
  "crv": "P-256"
}
.
{
  "sub": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
  "iss": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
  "client_id": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
  "aud": ["https://as.example"],
  "iat": 1761313600,
  "exp": 1761313900
}
.
signature
      

Authentication Credential Validation

For subject identifiers that use the did:key method, a verifier will extract a public key from the identifier itself, as described in Section 3.1.3 of "The did:key Method" [[did-key]]. Using this public key, the signature of the JWT MUST be validated as described in [[!RFC7515]], Section 5.2.

A verifier MUST validate all claims described by the authentication credential data model.

A verifier MUST ensure that the current time is before the time represented by the exp claim. Implementers MAY provide for some small leeway to account for clock skew.

Token Type Identifier

A self-issued JSON Web Token used as an authentication credential MUST use the urn:ietf:params:oauth:token-type:jwt URI when interacting with an authorization server.

Security Considerations

All security considerations described in "Best Current Practice for OAuth 2.0 Security" [[RFC9700]] and "OpenID Connect Core 1.0" Section 16 [[OPENID-CONNECT-CORE]] apply to this specification.

Privacy Considerations

A self-issued authentication credential using the did:key method embeds the public key directly in the subject identifier. Because the sub, iss, and client_id claims all share the same did:key: URI, verifiers and storage servers can correlate all activity from a given agent across sessions and resources.

Unlike the other authentication suites, the did:key method does not require dereferencing a remote resource during validation — the public key is derived directly from the identifier. This avoids the metadata leakage associated with network-based validation, as no third-party server is contacted during the credential verification process.

However, because the public key is encoded in the identifier itself, the did:key identifier is inherently long-lived and cannot be rotated without changing the agent's identity. An agent that needs to rotate keys while maintaining a stable identity is encouraged to use a different authentication suite, such as one based on controlled identifier documents.

Self-issued tokens presented to a storage server or authorization server can be read by those parties. The use of TLS is essential for protecting authentication credentials during transmission.