Note Taker: Kathleen Moriarty

Chair slides and overview - Yaron

Code of Conduct review

GNAP Editor Review of open issues

Justin Richer presenting for editors

Resource-server-01 (not many updates since last meeting)

Review some attacks and mitigations today
Diff between 6-8 should be viewed to see updates from last meeting
32 pull requests (core draft)
3 pull requests (RS draft)

Closed 55 issues
Many changes suggested from the community, catching errors in text
Changes outlined in slides and accessible in Git

New major sections outlined - security, trust, and privacy
Subject identifier and client instance identifier changes

More details provided on the outlined changes.
Trust model uses Promise theory - focuses on relationships between entities as opposed to the endpoints themseleves.

Security considerations section has 25 subsections and editors would like to get more reviews and contributions to make sure it is as complete as possible. Organization work is in progress.
Covers object and transport level considerations to have both integrity at the application layer and confidentiality at the transport layer.
Bearer token protections included, even though may be obvious to many it will help with consistency between implementations and deployments.
Cryto algorithms discussed and weaknesses pointed out if they are known.
Authorization mixup server attack addressed that came up recently.

Considerations included for attacks against other data structures, formats, and protocols used with GNAP added.

Please read through and provide feedback to catch what is possible prior to publication.

OAuth Security Workshop happening soon - free online event.
Core GNAP protocol to be covered by Justin
Fabien to present GNAP security analysis to get more review and analysis

First time GNAP is part of the OAuth agenda, so it's a good opportunity and things can still be fixed by the larger community.
OAuth Security Workshop

Privacy Considerations:
Followed RFC6973 for guidance

Yaron: Summarized the talking points of presentation and asked about correlation between the 2 drafts.
Justin: These sections have only been added to the core draft yet. It is expected that the RS draft will inherit much of the core draft, but additional content will be added specific to that draft. Tradeoffs of introspection for instance will be covered in RS draft.

Symmetric cryptography: allowed but restricted

Changes to User Handle - replaced with "subject information" opaque identifier to simplify protocol and maintain functionality

Effort has been made to simplify the protocol, but maintain features using core capabilities where possible

Client instance identifier under review to see if something similar can be done.

Formal GNAP security analysis:
Cuckoo token Attack reviewed, similarities to previous attacks and solutions discussed as well
This attack works for key bound access tokens, token is replayed, no access the key is needed
Client is tricked to using the token that is replayed
Diagram is provided
Editors have talked through this a bit with researchers and have proposed mitigations, not saying to do all of them
Mitigation options outlined on slide 17

Olle Johansson is asking in chat about mitigations that also apply to OAuth
Pedram Hosseyni asking how realistic is the second mitigation? Justin provided a response and will address this in the draft - use of different keys in MTLS as part of the security consideration.

307 Redirect attack covered - slide 18

Review and comments welcome to make the draft better.

Editors proposal for work between now and next meeting
Process issue backlog
No solution for key rotation yet, important to do
Probable direction presented - may not have one method
Text will be proposed in the next few months - issues covered before

Kathleen Moriarty asked about using ACME to help with the short lived certificates tying into the ACME client draft that provides an extension for new challenge types. Transparency log is used to help with short lived certificates in other use cases, including code signing certificates. The ACME client draft will be updated soon for another purpose to add OpenIdentity support. Here's a link: Look for updates soon and review appreciated.

Yaron skeptical about interoperability profiles - profiles should be a separate draft
Justin - the profiles may be by industry vertical
Kathleen - note on adoption being higher when a protocol is simpler, but allows for extension points

JOSE used in draft now in 2 places - slide 25
Should JOSe functions be in a separate draft? There are two other ways to address the same security properties, but there are tradeoffs. This will be discussed on list and security should be evaluated to see if multiple choices should be present.
Yaron - if security is the same - then slim down the draft

Implementation status section will be added to the draft. Core of protocol has remained quiet, so a good sign for stability of the protocol and to impplement.

Open discussion:

Second presentation: Denis Pinkas

Slides in datatracker meeting materials

Technical difficulties with getting slides to display.
Concerns with draft 8 with proposals to resolve concerns
Differences between access models and proposed support of attributes should be added to the core document
RBAC and Capability Based Access Controls (CBAC)
Reasons provided on slide 4
Distinctions between rights and attributes
Benefits discussed on slide 6
Questions trust relationships in slide 8
Denis asserts trust is binary, should be 0 or 1
Section 1.4 of draft 8, doesn't distinguish entities to a level where his assessment is that it is not complete
Buid detection mechanism discussed on slide 15
EU legislation should be considered - slide 16 - GDPR, payments, etc.

Chat of Meetecho includes sections to provide counter arguments to points made during presentation (pasted for completeness):
fabien imbault
See for some discussion on this08:31:07
attributes were discussed in
(and many other issues)08:45:06
Justin Richer
There is not a precondition of the RS and AS knowing each other ahead of time, this was discussed here: (and a number of other issues)08:47:25
fabien imbault
notice, choice, consent was discussed in, see last comment08:47:57
Justin Richer
Opaque access tokens were discussed here:
fabien imbault
We have examples at the beginning of section 4, where RO != end-user08:48:58
Justin Richer
We also have examples in the sequences and appendix where it's an automated process:…ml#name-software-only-authorization and…ol-08.html#name-no-user-involvement08:49:50
Another example where RO != End user is…l#name-asynchronous-authorization-208:50:13
fabien imbault
Section 4 of draft 8 does indicate those trust relationships08:50:20
Justin Richer
Nothing in the draft assumes single factor authentication
fabien imbault
This was discussed at length in
Justin Richer
A subject identifier within an access token does not prevent it from being shared.
different subject identifiers within an access token would be appropriate for the token model discussion in the RS draft, not within the core protocol08:55:43
(and none of these prevent token sharing)08:55:49

(Fabien: attributes were discussed in

Questions for Denis:
Fabien: Issues have been discussed at length in the git repository. If there is additional discussion or arguments against decisions made, please speak up. It is clear from discussion and agreement that the disucssed items won't be included.

Yaron requested additional comments and closed out the session.