GNAP at IETF-111
July 26, 2021.
Chairs: Yaron Sheffer, Leif Johansson and Kathleen Moriarty
Minute Taker: Kristina Yasuda
Agenda
-
19:00-19:10 UTC - Chair intro
-
19:10-19:30 GNAP interaction with VC-HTTP API W3C work, Adrian Gropper
-
19:30-20:50 Core protocol and Resource Server drafts - editors
-
20:50-21:00 Next steps: chairs
Minutes
GNAP interaction with VC-HTTP API W3C work, Adrian Gropper
Intro - Chief Tech Officer at a start-up (HIE of One), leads implementation of SSI protocols; has been involved in transition from UMA 1.0 -> 2.0
Agenda
- Will mainly cover Human Rights perspective on protocol design
- Efficiency shifts power to the sovereigns, not only individuals, but also enterprises
- DID data model standard alone is not enough, also need protocol standards, especially for Human Rights considerations
Human Rights Concerns
- Ambient authn (eg facial recognition); non-repudiable authn; anonymity barriers; strong creds; chain-of-custody; lack of agency; controls of free assembly; proprietary AI
What is Self-sovereign identity (SSI)?
- An identity that only you control
- DID as a component. in a DID Document that you control, you have a service endpoint, which is a demarcation point between what is protected and what is public
- Everything else is sovereign (enterprise)
- Control model is direct or delegated
- Direct: possession of a wallet; messaging adress such as email, etc.
- Delegated: AS
The future of the Internet and how to stop it J.Zittrain adaptation
W3C and DIF Protocol [sic: SIOP is OIDF] Work
- VC-HTTP-API
- EDV - Encrypted Data Vaults
- Identity Hubs
- DIDComm - message lv security
- SIOP - Self-Issued OpenID Provider (OIDC)
Five questions
- How many authz protocols does the internet need? (other than GNAP)
- The problem with OAuth is lock-in and censorship (via client credentials)
- Self-Sovereign and Fiduciary agents
- How to detach "chain of custody" from verification (w/o biometrics)?
- Is GNAP the "narrow waist" of SSI?
Resources
QA
-
Justin Richer: Number of ways VC-HTTP-API and GNAP can be used together (ex: GNAP can be used to protect calls to VC HTTP API). Where you view centrality of the protocol - ie GNAP can be used in the process of gathering the creds that will be used at the API. Depending on the way you look at it, GNAP is not a "narrow waist". What engagements are you looking from GNAP group at VC-HTTP-API?
- 1/ We must not ignore delegation - it is a Human Right. 2/ take up this issue in GNAP appendix protocols on top of DID/VCs; or start a new group to tackle this issue.
-
Aaron Parecki: Understand the concerns with current deployments. Nothing in OAuth itself that requires the relationshiop between the client and AS - for example Dynamic Client Registration allows to do it at run-time. How do you prevent this from preventing in other protocols.
- UMA profile of OAuth might be relevant (Justin also has experience here)
-
Robin Wilton: What is in this model that prevents RP from telling the user: give me everything or you cannot access this service.
- Issue of delegation. Needs to be done correctly
Core protocol and Resource Server drafts - editors (Justin, Aaron, Fabian)
Update: WG now has two drafts.
Core draft update (-04 to -06)
-
Functional Changes
- Update discovery mechanism
- Client instance to do a pre-flight call to Authz server to figure out parameters, etc. Functionally optional in GNAP. Negotiation nature of the protocol allows talking to an arbitrary installation and figure out what's going on. Now also possible to figure out before-hand to reduce optionality in the req.
- Fairly lightweight
- Subject Identifiers (syntax changes; subject identifier format; add DID examples)
- Allows to identify who the user/Client Server is. Without additional APIs can say WHO is involved in the transaction.
- Cryptography/Signing
- DPoP
- Normalize htu claim
- Editorial changes for JWS
- Access tokens
- Type parameter for JWS methods
- Describing keys
- Crypto requirements
- Cache-control header
- Extracting the RS communication into its own spec
- Authz interaction
- Options to interact with the user): goes to the URL at the authz server. sending the user to the server. not necessarily core to the protocol. Client can facilitate the interaction between the user and different servers. (#242)
- Non-normative changes, but clarified language around redirects, etc.
- Relationship with VC-HTTP-API: GNAP protects VC-HTTP-API that is used by the client instance to tell the AS "I've got VCs about the user at this endpoint (VC-HTTP-API)". Does not necessarily need to be in GNAP core?
- Privileges field
- Def of
scope controlled by the controlled API - same as in OAuth
- Syncing language with RAR
- Added new parameter for mixup (later)
- Removed features
- Extension capabilities and existing grant
- DPoP
- OAuth PoP
-
Editorial Changes
- Fixing some examples (some JWT examples were broken)
- Fixing Typos
- Updating diagrams
- Protocol rationale (why certain things are done the way they are)
- Updates flags for consistency
- Additional
editorconfig for document consistency- Post -06 typo fixes
Update on a new draft (Resource Server draft)
Mixed-up attack discovered researchers at Chalmers University of Technology in Sweden
- By: Åke Axeland and Omar Oueidat
- Mitigation proposed
- How it works
- How is different from OAuth 2.0
- Client requests ate bound to keys instead of bare secrets: no impersonation on the wire
- Access token is (normally) bound to a key
- Diagram
- Players
- AAS - attacker AS
- HAS - Honest AS
- AAS acting like a proxy to HAS; Attacker would have to have a registered client with HAS
- AAS has both client and server nonces because it proxied
- AAS signes using AAS's keys - not impersonation
- Result: Attacker has access approved by the client
- Substituting client - making user approve not what they think and attacker receiving access token
- Mitigation (already in GNAP -06)
- Overall: passing info about AS to the client
- A simple addition: including grant req URL in the interaction hash prevents creation of a new parameter (string gets added to teh calculation)
- Nothing more added, reusing what client already has
- Wrap-up on mitigation discussion
Removed/modified features
- OAuth PoP -> HTTPS message signatures, potentially
- DPoP never meant as a signature method
- Current direction HTTPS message signature as mandatory, since mTLS is context-specific
- Removed because no one was using - antipattern in security protocols to keep something that is not currently used, but MAY be used. can be revived if the need arises
-
- Give me something new in the existing context - was confusing
- Coming from advanced user-management
- Could be added back, same rationale as for
capabilities
- Q from Adrian: for SSI delegation, RO interacting with RS - preregistration of AS that RS has to agree to
- Not what capabilities field indicates. security notion of capability, ie Credential bound to the destination. URL with access token attached.
- How do we dynamically introduce ROs to this space - authz gathering section is about that
-
- Could be added back, same rationale as above
Drafts next steps
- Key is used as SW identity all over GNAP, but reliance on PKI is not baked in
- What are the assumptions we make around entities and roles - need to be explicitly documented
- Core draft is stable, ready to fill out security and privacy considerations
Implementations
- Dependency on HTTP messaging and secevent identifiers implementations/libraries
General discussion
- Denis Pinkas: needs different treatment of access token depending on whether it includes attributes or rights (related ot the access controls)
- A closed issue has been reopened 6 days ago: #295 In practice, only rights are supported but attributes should also be supported It is currently opened. This issue would need to be addressed. Attributes are personal data and should only be released to the RS with the consent of the user, once the user has been able to be informed for which reason each requested attribute is needed and how it will be used by the RS.
- Denis: Section 7 (Securing Requests from the Client Instance) states:
“In GNAP, the client instance secures its requests to the AS (…) by presenting an access token, presenting proof of a key that it possesses, or both an access token and key proof together”.
The Security Considerations section states: All requests have to be over TLS or equivalent.
If the authentication exchange between the user and the AS is also protected using TLS, then it is no more necessary to manage client instance keys.
This would allow many simplifications.
- Aaron: have not seen how only using TLS can bring hte same lv of security as client keys protection. Client instance keys allows to bind access token to a particular instance, so that it cannot be replayed. with just HTTPS you cannot do that.
- Jamey Sharp: suggestion refine generic HTTP resource type, or to have IANA registry for resource types, so that you can have common ones, ie AS discovery.
- Resource and access rights, types are left unassessed here, since assumes client knows what kind of resources it is asking for.
- Can we use GNAP for HTTP resources?
- Justin: intersting. notion of registering the types has been discussed. consensus, do not want to require registration, but having a catalogue is useful - IANA is not for that.
WG Next steps
- Proposal for a Security Workshop (Kathleen)
- Separate/together with OAuth Security Workshop?
- Robin: may not attract large audience, but is a good idea
- More next steps (Yaron)
- Over 100 new issues (document is not stable yet); need to bring down to 10-ish
- Need a thorough security review
- Roman: how about interop testing/matrix?
- Justin - not enough implemenations to have a meaningful matrix. Might need something like OIDF's automated conformance testing - it is open-sourced https://gitlab.com/openid/conformance-suite, can be used as a basis in GNAP
- Yaron: main deliverable is a document, not tooling, and the focus should stay there
- Yaron: encourages to read both drafts and especially feedback from those participating in both OAuth and GNAP WGs - to clarify the relationship with and updates to OAuth.