HTTP APIs for CredX?

Daniel Hardman*, CCG, April 2021

*Participating as an unaffiliated individual, not as a representative of my employer. Signed W3C Community Contributor License Agreement as an individual.

Background

Email thread, Dec 2019: https://j.mp/3dJtIGA

Open issue on VC HTTP API repo: https://github.com/w3c-ccg/vc-http-api/issues/50

DID use case: https://j.mp/3aD7lAR (and medium article about it)

​

Korean Conglomerate Use Case

• Access control for hundreds of thousands of employees who clock in every day
• Very intense ~30 min spikes around shift changes
• Any brownout / downtime = lost productivity

graphics by lavarmsg/Vecteezy, trex/Freepik, jon trillana/The Noun Project

A

B

Uber Use Case

Photo by Dan Gold on Unsplash

Riders who aren't running web servers, and who can't reach web servers, still want to ask for and get proof on their mobile phones.

Visa Use Case

• Interactions unfold over weeks, not seconds or minutes (human latency)
• Email, chat, phone
• Parties are in different timezones

Photo by dcgreer/Flickr

Offline payments use case

• KYC — but offline
• Regulatory compliance
• Disaster / backup system

Choosing Our Target

Are the use cases outside HTTP's sweet spot legit?

​

Do we want to wrest HTTP to cover more — or accept multiple transports?

​

What happens to funding and schedules for everything outside the sweet spot of only the sweet spot is "standard"?

​

Design target doesn't have to equal initial impl target.

​

​

HTTP sweet spot:�institutions, realtime, online

Recommendations

←DIF Pres X + sequencing, semantics synthesized from Aries, VC HTTP API, WACI, GNAP

XMPP

NFC

Coalescing Standard for CredX payloads and sequence

propose ~ offer ~ prove (timeouts? negotiation? ACKs? Errors? Ts&Cs?)

Standard for transport-agnostic encryption envelope

HTTP

existing transport security (TLS, S/MIME, Signal, Noise...)

BLE

email

←JWE / DIDComm

New Std

Sneakernet

W3C

IETF

DIF