7B/ Introduction to GNAP
Introduction to GNAP
Session Convener: Justin R
Notes-taker(s): Charles E. Lehner, 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:
https://celehner.com/2022/04/27/gnap.txt
PICTURE MISSING
Speaking to OAuth2 limitations and things bolted on
GNAP: looking for common abstractions in those bolt-ons
Primary design pillars
- Consistent protocol across many different use cases
- OAuth: too many flows, lots of questions to ask in order to decide which flow
- Desire a protocol which allows you to start things the same way and then decide further in the flow
Client (C) always starts with a call to AS (http POST)
- Who I am, what I want, what I know, what I can do
- In OAuth, the who is clientID. Its a bad abstraction. Big topic of conversation at OAuth WG in last IETF mtg
Next pillar: Avoid expensive discovery operations in the protocols
- Ex: mobile device can generate device attestation along with self issued key in an MDM env.
What I want:
- Ask for an access token
RAR-kind of info in the request
- RAR is a backport of this piece of GNAP (speaker is coauthor on RAR as well)
- JSON array of objects, watch with…
- Type [ … ]
- Actions: [ … ]
- Locations: [ … ]
- Gives you a very rich set of expressions without having to cram it into scopes
When the RS might be getting different information (that the client never actually sees)
In GNAP we make subject info is its own first class citizen
Situation: Client may already know who the user is — say, a VC
- Simplifies the flows
Grant types
Q: How do we start A: One way is that the RS can redirect the client to the AS Also have a provision to allow AS and RS to communicate (client never sees this) Most common will likely be that developer just specifieds the AS
“What can I do”...
- Client can say I want to do A, B, C
- AS can reply with only B, depending on resource you want
Response:
- Continuation, which is used for interaction with RS?
Status:
- Core spec has been stable in terms of syntax and core functionality for 6-9mo now (lot of churn before that)
- Biggest recent change: user code split into two things
- Security considerations in work with security researchers
- Stability: core spec stable, but will probably see some changes as implementations move forward
- Biggest ref implementation is the XYZ impl by Justin (oauth.xyz)
- Google :”GNAP IETF Hackathon”
- SecureKey is using this as part of a nextGen of one of their products
