OAuth3: a handbook for permissionless interop
A living doc for discussions and iterations.
The Overdelegation problem
Teleport
Even websites that support delegation to third party apps, delegation is limited.
… but nothing in between
(also DelegaTEE Usenix’18)
Teleport for Twitter
Every Teleport is an NFT on (Base) OpenSea
Limitations of Web2 Delegation addressable w/ TEEs
1. Permissionless Provenance. Oauth2 providers don’t sign their TLS traffic.� Solution: Proofs of Data Provenance (using zkTLS or TEE)
2. Permissionless Delegation. Oauth2 providers don’t provide extensible account delegation primitives� Solution: Fine grained delegation
3. Permissionless Commitments. Oauth2 providers provide no mechanism to “attenuate” authority.� Solution: TEEs password managers that contain user passwords etc
4. Permissionless Account Abstraction. OAuth2 providers don’t implement progressive security mechanisms like passkeys� Solution: Implement passkeys at the authorization proxy
Need for Permissionless Interop beyond OAuth2
Identity Provider / �Account Issuer
Relying Party / App developer
User
Only the IdP can define delegation “scopes”
The app must be trusted not to violate stated policies
Today:
Need for Permissionless Interop beyond OAuth2
User
Authorization TEE/MPC Proxy
Proposed:
TEE Based proxy. Handles OAuth, as well as password & browser use
Presents enforceable claims to the user
Identity Provider / �Account Issuer
Relying Party / App developer
Example: Teleport
User
“I need the ability to post one “safe” tweet per day for a month.”
Authorization TEE Proxy
Read/Write OAuth
“Authorize App for the the following:
- 1 tweet per day
- Expires after 1 month
- Filter: “safe” template”
Identity Provider / �Account Issuer
Relying Party / App developer
Example: Timeline peek
User
“This app will allow you to share your timelines (For You and Following)”
Authorization TEE Proxy
“Authorize App for the the following:
- View your “For You” and “Following” timelines
Identity Provider / �Account Issuer
Relying Party / App developer
Password
Session
Example: Bring passkeys
User
Authorization TEE Proxy
“Sign into your Gmail account using your eth wallet”
Gmail
Twitter or Eth
Session
OAuth3 Reference Implementation�v0.1: Twitter
Problem statement: Eliza Twitter Helper
OAuth3 Reference Implementation�v0.2: Telegram+Twitter
app
User
Authorization TEE Proxy
Twitter�Telegram
OAuth2 scopes: � tweet.post � telegram.post[{chan}]
passkeys
telegram login/code/pw
twitter auth_token
User specifies policy
App requests, user approves
app
Users Login via Passkeys, and adds Telegram
Twitter auth_token session (undocumented api)
Telegram Public API
Uses OAuth2 tokens to describe refined scope
Question: We can pack ANYTHING in the OAuth scope strings. Doesn’t have to be an enum. Could be LLM policy. �What do we want?
This is for twitter only, �not telegram
Integrations Implemented so far
| Public API | Undoc API | Browser | Encumbrance |
| Twitter-api-client | | | |
Telegram | Telethon | | | |
… | | | | |
References
PRD (doc)
Implementation https://github.com/amiller/oauth3-twitter-client
Issues: �Adding oauth https://github.com/amiller/oauth3-twitter-client/issues/6�Passkeys: https://github.com/amiller/oauth3-twitter-client/issues/5�Telegram integration: https://github.com/amiller/oauth3-twitter-client/issues/10
Framework for OAuth3 �use cases & product design space
| Read | Write |
Web3 | | |
Web2 | | |
privy
liquefaction
teleport
zktls
Understanding the Web2 <-> Web3 Interaction
Oauth3 “product design” space: Accounts and Actions
| Read | Post w/ filter | Punish | Bundle | Backstop | Redistribute | Find complements |
Web3 JWTs | | | | | | | |
| Teleport | Lending | Flashmob | | Follower exchange | Subliminal Marketing | |
Telegram | | | | | | | |
Docusign | | | | | | | |
Cloud | | Light TEE | | | | | |
| | | | | | |
DAO groupchat
DAO owned email
discussion
Opportunity: Define OAuth 3 for Permissionless Interop
Legal co-design: users keep ownership of their accounts
Authorization Proxy is a “TEE Based Password Manager.”
The password manager enables users to create “credible commitments” about their account, to create data provenance proofs,
The user “owns” the VM that holds their accounts, despite the fact that the VM imposes limitations on its use
user
Password Manager �VM in TEE
Devs, Cloud
provide software, infra
Opportunity: Define OAuth 3 for Permissionless Interop
United narrative including:
- zkTLS & teeTLS
- Privy/
1. 0-Click Delegation of accounts� “I will delegate my account to any app that Carol curator endorses”
2. Dynamic delegation.� Suppose I authorize an “undeletable teleport” app that locks me out of
Open Questions in Account Encumbrance
- Robustness and mitigations of account encumbrance� “Complete Knowledge”
- Further refinement of best practices around TEE application upgrades
- Policy and terms of use boundaries regarding encumbrance and delegation� Starting points: barabender et al.
- Speculation-bounded fair token mechanisms for launches
- Social Marketmaking: continue analogy of social media audience as blockspace
OAuth3 Entities
User
Authorization TEE/MPC Proxy
Identity Provider / �Account Issuer
Relying Party / App developer
Need for Permissionless Interop beyond OAuth2
User
Requests �narrowly scoped authority
Authorization TEE Proxy
Proposed:
TEE Based proxy. Handles OAuth, as well as password & browser use
Presents enforceable claims to the user
Identity Provider / �Account Issuer
Relying Party / App developer
Passkeys�JWTs
session keys (replicated to multiple devices)