Hash Web Token (HWT)

documentation officielle issues discussions

Un protocole de token sans état, natif au réseau, pour la délégation inter-domaines.

Les tokens sont signés par une origine émettrice (issuer), vérifiables par toute partie pouvant atteindre le domaine de l'émetteur, et portent le contexte d'autorisation littéralement ou par référence.

Statut : Brouillon v0.7.

Ce que HWT fait

Ce que HWT ne couvre pas

Format du token

hwt.signature.key-id.expires-unix-seconds.format.payload

Six champs séparés par des points. Le point est le séparateur de champs et NE DOIT PAS apparaître dans key-id, format ou le nom de niveau supérieur.

format déclare le codec. j (JSON) est le seul codec requis. Les codecs communautaires supplémentaires sont documentés dans CONVENTIONS.md.

L'expiration est structurelle — un token dépassant sa valeur expires est inconditionnellement invalide, quelle que soit la validité de la signature.

Exemple de chaîne de délégation

Trois sauts : un utilisateur auprès d'un fournisseur d'identité → un agent d'orchestration → un service worker → la cible API finale.

Token racine (détenu par l'utilisateur, émis par auth.example.com) :

{
  "iss": "https://auth.example.com",
  "sub": "user:4503599627370495",
  "tid": "root-a1b2",
  "authz": { "scheme": "RBAC/1.0.2", "roles": ["editor"] }
}

Token intermédiaire (émis par agent.example.com pour le worker) :

{
  "iss": "https://agent.example.com",
  "sub": "svc:orchestrator",
  "aud": "https://worker.example.com",
  "tid": "mid-c3d4",
  "authz": { "scheme": "RBAC/1.0.2", "roles": ["editor"] },
  "del": [
    { "iss": "https://auth.example.com", "sub": "user:4503599627370495", "tid": "root-a1b2" }
  ]
}

Token dérivé final (émis par worker.example.com pour l'API cible) :

{
  "iss": "https://worker.example.com",
  "sub": "svc:worker",
  "aud": "https://api.target.example.com",
  "tid": "final-e5f6",
  "authz": { "scheme": "RBAC/1.0.2", "roles": ["editor"] },
  "del": [
    { "iss": "https://auth.example.com", "sub": "user:4503599627370495", "tid": "root-a1b2" },
    { "iss": "https://agent.example.com", "sub": "svc:orchestrator", "tid": "mid-c3d4" }
  ]
}

L'API cible vérifie la signature du token final contre les clés publiées de worker.example.com, confirme que la chaîne del est structurellement intacte (elle est couverte par la signature externe), et peut retracer l'ensemble de la lignée d'autorisation jusqu'à l'utilisateur d'origine. L'autorisation n'a pas été élevée à aucun saut — roles: ["editor"] tout au long de la chaîne.

Découverte de clé

GET https://{issuer-domain}/.well-known/hwt-keys.json

Format JWKS (RFC 7517). alg par clé est obligatoire. Plusieurs clés simultanées supportées pour la rotation.

Métadonnées d'origine

GET https://{issuer-domain}/.well-known/hwt.json

Déclare l'URL de l'émetteur, la version du protocole, les schémas authz supportés, la configuration de l'audience, la limite de profondeur de délégation et les URL des points de terminaison.

Modèle de confiance

L'ancre de confiance est le domaine de l'émetteur, pas une autorité centrale. La vérification dépend de la résolution correcte du DNS et de la connexion TLS au point de terminaison well-known de l'émetteur. La posture de production recommandée est un allowlist d'émetteurs pré-enregistrés — les vérificateurs rejettent les tokens d'émetteurs absents de la liste, convertissant la découverte de clé en une recherche dans un cache local sans dépendance DNS à l'exécution.

Documentation

Implémentations

Bibliothèque de référence

Démos

Licence

Licence Apache 2.0