OpenPubkey

  • Name: OpenPubkey
  • URL: https://github.com/openpubkey/openpubkey
  • Category: OIDC identity-to-public-key binding protocol / proof-of-possession auth middleware / artifact-signing identity primitive
  • Summary: OpenPubkey is best understood not as a full signing product or a generic login SDK, but as a lower-layer protocol for turning OpenID Connect identity assertions into certificate-like bindings to user- or workload-held public keys. Its core move is to make an OpenID Provider-signed ID token commit to a public key—via the nonce field for users and the aud field for workloads—then extend that token into a PK Token that proves both identity control and private-key control. The reusable mechanism insight is that OpenPubkey separates identity-provider authentication, ephemeral key generation, key commitment, proof-of-possession packaging, replay protection, and historical verification of rotated issuer keys into a comparison-ready trust stack.
  • What it does:
    • Binds an existing OpenID Connect identity to a user- or workload-generated public key without requiring changes from the OpenID Provider
    • Turns an ID token into a certificate-like PK Token that can travel alongside signed messages or artifacts
    • Lets users or workloads sign messages under identities issued by providers like Google, Microsoft, Okta, Keycloak, or GitHub Actions
    • Uses the nonce mechanism for user identities and the aud field for workload identities to smuggle key commitments through standard OIDC flows
    • Adds optional GQ-signature-based proof transformation so public PK Tokens do not expose replayable raw OIDC bearer tokens
    • Supports or motivates downstream tools such as OpenPubkey SSH (opkssh) and artifact-signing flows like Docker Official Image signing
  • Key claims:
    • The strongest analytical move in the primary materials is that OpenPubkey reuses the OpenID Provider as the certificate issuer rather than introducing a new CA to bind identity to a public key.
    • The protocol is intentionally lower-layer than Sigstore or other end-to-end signing systems. The FAQ is explicit that OpenPubkey only solves the identity-to-public-key binding part of a larger signing stack.
    • The README’s PK Token framing is useful because it exposes the actual decomposition: OIDC identity proof, user-controlled signing key, OpenID-signed commitment, and verifier-side extraction of the committed key.
    • The workload-identity branch is especially important because it reveals a slightly different control surface: when nonce is unavailable, the identity-binding path shifts into the aud claim and the replay-protection story becomes more operationally important.
    • The FAQ’s GQ-signature section is one of the most important practical details. It shows that once PK Tokens become public, raw ID tokens create bearer-token replay risk unless the OP signature is replaced with a proof of authentication.
    • Historical verification is also a real control surface here. The primary materials repeatedly note that OpenID Provider JWK rotation makes long-lived verification hard, which pushes trust into archival verifiers, TUF-distributed key histories, or transparency-log-style key ledgers.
    • OpenPubkey belongs in the corpus because it gives the wallet/auth/signing cluster a useful comparison point beneath full artifact-signing products, social-login wallets, and DID systems: it isolates identity-provider trust, key commitment, proof-of-possession, replay defense, and issuer-key-history custody as separate layers.
  • Whitepaper: The canonical paper is the IACR ePrint OpenPubkey: Augmenting OpenID Connect with User held Signing Keys (2023/296). Supporting primary materials and implementation notes are collected in ../whitepapers/openpubkey-primary-sources-2026-05-13.md.
  • Sources:

Internal linkages

  • Best direct comparison points: caip-122, did-pkh, and zk-email.
  • Keep the note on identity-to-key binding and proof-of-possession, not on every higher-layer credential stack that could ride on top.
  • Last reviewed: 2026-05-13 UTC