OAuth is being used for a lot of stuff, that it was not meant to do. How like dealing with ephemeral clients securely 2010: SPAs not that big, mobile apps were the future ephemeral client with same client id -> hard to have security model based on that client id. refresh browser -> new application things patched into oauth2 Pixie to make oauth2 behave better oauth with its bolted-on stuff looked for common abstractions, patterns what all the bits and pieces would look like if we had taken those things into account in the beginning end up with similar diagram, but different ways the parts communicate design pillars consistency across use cases Book on OAuth2 - Manning Press gigantic graph -> first decide which flow type. ask nature of client, delegation, and other stuff. every single OAuth2 flow type starts differently auth flow starts with redirect others start with POSTs to various endpoints have a protocol allowing starting processes the same way and then negotiate forward the rest of the process GNAP always starts with client POST to AS (authorization server) HTTP POST with JSON body since OAuth, JSON is big, no more form parameters. big difference for developers and for the protocol expressiveness What the client sends in the initial POST request: - Who I am - What I want - What I know - What I can do In OAuth, "who I am" is the client ID. Always need client ID, whether static or dynamic, etc. Bad abstraction. OAuth2 WG struggling with definition of client ID that doesn't fit with reality anymore Client can prove possession of key How to use keys... HTTP Signatures Mutual TLS GNAP is open about it. But still starts with the same backchannel connection Without prior knowledge of the AS, other than the initial URL, can send the initial msg. If AS doesn't support it, just one round-trip. Pillar: Don't have to do expensive discovery, registration, configuration. Protocol has to work in a dynamic environment. You can pre-register stuff, can limit which keys, reference key by identifier - similar to a preregistered oauth2 client id; but at a protocol level it's an optimization rather than a foundational element. Protocol design: make sure the bits and pieces are optimizations where they make sense. Allows doing advanced things. Mobile device - keys on device; prove with attestation. Bootstrap trust GNAP: dynamic negotiation of the terms of the transaction What I want... I can ask for an access token (This is an API access delegation protocol at its heart). In OAuth2 you have strings (space-separated values, a set of known identifiers). In GNAP, need to have it more expressive. Pass key by identifier or by value. Can pass request e.g. ["email", "profile"] Can use a JSON array because no longer limited to query parameters like in OAuth Can send array of objects rather than strings [ { type: data_api, actions: [...] locations: [...] }, {...} ] API-specific JSON objects. Just type field is required. Not JSON-LD, although could be. Not requiring dynamic lookup. Defined common fields. Can put more stuff in the list. Rich authorization requests (RAR): Backport of this part of GNAP into OAuth2 GNAP is smoother since it's built with this from the start In OAuth2, have to deal with scopes, resources, and audience parameter. Kinda mean the same thing, kinda don't. In GNAP, same kind of semantic thing. Just by value or reference. Can replace some well-known objects with strings [ "email", "profile", {...}, {...} ] Many dimensions of expression in the grant request. While still allowing the simple cases. In RAR, combining scopes and other things gets messy. In GNAP, we can say that each unit in the list must be understood in some way. RS (Resource Server) might get additional information... e.g. Client doesn't necessarily need to know account number. Separating the models is not so clear in OAuth2. Also want information about the current user. "Who is logged in right now" OpenID Connect: pasted ID token alongside access token. Metadata seems like it might apply to access token but it doesn't Extensible, pluggable assertions and formats. Client may want to present to the user. If have VC, then doesn't need to ask the user; don't need to do redirects to get started. What I can do... Grant types: real difference between the OAuth2 flows is the means of interaction. How getting involved in the process. The brilliant thing that OAuth and OpenID brought to the table in that era. Previously protocols process policy in the background. If you were lucky you could present a username and password. OAuth and OpenID involved the user by having them go through a redirect process. OAuth: abstracts it by saying what are the ways to interact. Can have extensions, e.g. for DIDComm, or to query a wallet to get a VC. Client can send its info as part of its initial request. Basically telling the AS how to get more info. Client and AS start the negotation of anything that is allowed to happen next. GNAP doesn't care how you find out about the AS; you just need the one URL to get started. If client asks RS, RS could return WWW-Authenticate header to say go to GNAP at this URL. If RS can say "ask for this bundle" RS can go to AS to ask for an identifier representing rights. GNAP-RS specification, not the core GNAP specificaiton Confused RS attacks: replace token endpoint with my own. Discovery: HTTP OPTIONS request to the main URL. No .well-known URI. Respones to client: JSON document. AS can make decision to ask for other things. Continuation: contains an access token, a URL, and other bits. continue: { at: ..., url: ... } Core spec says how to send the key, dynamic registration. Future features: device attestation, device geolocation, etc., need experts to step up. API to get access tokens, protected with an access token. Bound to same key method client used in initial request. So when you make the continuation request, you've already done the protocol. Continuation URL... Interaction reference, important security aspects... GNAP just needs to know how to start and how to get back. When the user is back, and the client knows it, we call the continuation. Functionally part of the AS, but doesn't have to be deployed there. Architecture could allow for separation. OAuth is already deployed this way. Google: Authorization endpoint and token endpoint are on different domains. Want GNAP to allow this - different security domains. Different functions: dealing with person, talking with machines. Probably have internal coordination mechanism. Stateful protocol. Issue: write the state machine explicitly. Multi-step, multi-party process. Question about equests with previous access token (no refresh token?) client credentials flow is request-response. A: AS could give access without additional requirements. Presenting assertions to the AS. Client would receive failure and start new flow. With GNAP, it's all bundled together. "Here's my assertion, if that doesn't work I can redirect the user". Basic client credentials flow, leave off the user part ("I can't interact with the user, and don't expect to") and it succeeds or fails. Interaction... don't need access token? Probably only do for multi-step thing. But it still makes sense to allow it. Conditions to allow access might not be permanent for the client. e.g. a known network device goes into the field, access token expires; continuation says to refresh the current state of the request - instead of having to restart and re-present. This is for user interaction... sent the user somewhere, lost them (by design), then get them back and continue. Q: IdP? A: OAuth doesn't use IdPs, OpenID Connect uses IdPs. Login to AS with federated login: redirect to the AS, and AS decides how to deal with it... same. Q: Stability/maturity, implementation, gaps? Hit the continuation: tells the AS I'm the same client as before; don't have to send key again. Moving forward with transaction, calling API on AS with access token I was issued. In GNAP, by default all access tokens are bound to the key that was presented, and the method used initially. Can get a bearer token with special flag, but that's not allowed for the continuation. Q: key? A: AS may allow different key method. Could do shared key here but strongly discouraged. Q: making request and having continuation: is specific to GNAP, or in other protocols? VC API A: Can copy this but it's not GNAP. Can start with different protocol (not GNAP), and have a GNAP response, and then instead of a GNAP completion message have the API response? People are trying to do it... but separation of protocol may be better? Access token from GNAP a_t: { val: ..., key: ..., flags..., label:..., access:... } access token is its own data structure. Problem with OAuth is that the access token and its metadata are top-level properties. GNAP tries to make it clear what applies to the access token. But still opaque to the client. If client needs to know about it, it goes up a level. Directed access token. Not capability. Client doesn't need to understand or parse token value. Gets token value and metadata saying where to apply it. Metadata: access token and value. Q: scoping to client how access token should be used. flags...? A: no... Multiple access tokens... Access token could be an array of tokens, each with a unique label. Q: how related to original request? type? A: access token request: client defines label. other values under label. Can get effective access array in response that was applied. JSON polymorphism (object or string or array): being uesd in a precise way. GNAP is indended to be implementble in strongly-typed lanauges. Using the token: already know how to do that, since call to AS is protected similarly. Negotiation at runtime: client asks for everything at once, and gets stuff back. Q: Status of spec? A: Stable in terms of syntax and core functionality for 6-9 months. Recent change: user code that might or might have a URI - split into two things. 1: get just the user code. 2: get user code with URI for user to type, not including the user code. Looking over for security considerations. Major security issues of OAuth2 have been "designed out". Don't need Pixie. OAuth: push authorization request: if authenticated (yet another endpoint), don't need Pixie. OAuth: if X, maybe don't need Y. GNAP: one way to do things. Spec is pretty solid and stable. But may have some bikeshedding. Biggest reference implementation: XYZ project: Java Spring, Jaxon, HTTP Signatures https://oauth.xyz/ SecureKey (Avast) using this for multiple access tokens, dynamic key management. Hoping to be in production this year Not widespread commercial deployments yet. Specs take a long time, especially security. People doing graduate work trying to break it.