10B/ ZKP’s & API Access

From IIW

Securing API Access with ZKS

Session Convener: Seth Back

Notes-taker(s): Steve Venema

Tags / links to resources / technology discussed, related to this session:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

20 attendees

API Access Threat model

  • Tampering with data in transit
  • Replay f requests
  • Unauthorized access to data
  • Exploiting implicit trust
    • (external -> internal / internal -> internal)

API tokens

  • Pros
    • Single token
    • No special computation
  • Cons
    • Relies on transport security
    • No request integrity

Public / Secret Token (e.g., AWS token)

  • Prosure over specific data
  • Without exposing that signature
  • In a format that can be publicly verified
    • Secret is actually a secret
    • Request integrity
  • Cons
    • Arbitrary connection between tokens
    • Implicit trust / over provisioning access

What do we mean by ZKP in this context (PS Signatures)

  • Prove knowledge of a signature


  • Sig…

Implementation: Oberon

Trinsic’s use

  • Login generates “token” tied to the account
  • Blinded before returned (2FA / no reliance on transport security)
  • Nonce includes timestamp and request hash
  • Validation at service level using public key


  • Oberon ver=1, proof=asdfasdf, data=afafasd, nonce=asdfasdfadf

Q: You mentioned macaroons; can you go into more detail?

A: whitepaper, a way to use hashes on signatures to attenuate authority

Do a ZKP on the macaroon – seen this used

Q: Combining API keys, access tokens, OAuth2 tokens

Nonce is different each time. Can …

Biggest value: Never have the API token pass over the wire

C: RFC8749Http structured headers – encouraging use of this in the future

Another version of Oberon coming out

Q: What formats supported

A: You are generating a ZKP of the hash of *any* data