Minutes interim-2021-gnap-05: Tue 19:00
minutes-interim-2021-gnap-05-202110051900-00

GNAP interim meeting, 2021-10-05

Chairs: Leif Johansson and Yaron Sheffer

Note taker: Peter Yee

Justin Richer (Bespoke Engineering) gave an overview of topics and the what the
editors are thinking along with a summary of some of the discussions on the
mailing list and GitHub issue trackers.

* Core draft update – last update has now been out for 1.5 weeks. Changes cover
four areas:

+ The user handle syntax has been collapsed. The “extra”, special field is no
longer needed. Now the client instance can send the opaque “subject
information” identifier in place of the user handle. This was always possible,
but now it is the only way.

  + Trust relationships – these are defined using promise theory. This doesn’t
  change the requirements, but it does change how we do it. The interactions
  between the actors in the protocols are specified. Denis Pinkas (DP Security
  Consulting) doesn’t agree that the text defines a trust relationship. ISO
  defines a trust relationship as between entities for specific interactions.
  He has his own Internet-Draft that has a different take on the trust model
  and would like to see it considered here. Fabien Imbault (acert.io) says this
  is initial text, so there may be missing relationships. Client to
  authorization server is a complex relationship, so it hasn’t yet been
  included. Richer doesn’t feel that the ISO trust relationship model is the
  only valid model and he feels that the one in the core Internet-Draft has its
  own advantages. He admits that more work is needed to complete its
  description. Adrian Gropper (HIE of One) asks whether it would make sense to
  consider a zero-trust architecture (ala NIST) and discuss that explicitly in
  the document. Richer says that zero-trust architectures are brilliant, but
  that’s not what’s being talked about here. Zero-trust in his mind is
  pre-establishing trust based on an authority. What’s in this document is a
  different concept: what those relationships mean after they have been formed.
  Gropper feels that zero-trust introduces many concepts that are relevant to
  the core protocol, although the document doesn’t have to use the zero-trust
  terms to describe them. Pinkas wants Richer to discuss attribute vs.
  capability models; Richer said this has been discussed before.

  + Security considerations have been added in the form of 21 subsections. This
  is the initial cut; more are expected. This is a very wide look at potential
  security considerations given this is a security protocol. Trade-offs in
  using various features such as bearer tokens are considered as well, so that
  informed choices can be made. Input is requested to fill in unknown holes.
  Pinkas feels the document is incomplete because it doesn’t define the
  structure of an access token, therefore it is only a framework. Yaron Sheffer
  requested that Pinkas bring up his own Internet-Draft on the mailing list
  instead of relitigating issues outside of the topics being discussed.

  + Privacy considerations have also been fleshed out, noted Aaron Parecki
  (Okta). They have been modeled like RFC 6973 to the extent it applies to this
  specification. The main topics covered are surveillance (client,
  authorization server), stored data, intrusion, correlation (by clients,
  resource servers, authorization servers), and disclosure in shared
  references. This section shows how GNAP relates to each of these topics.
  Sheffer asks whether we know that the formalism in the trust relationships is
  actually being used by the teams and tools that are doing verification of
  such protocols. Imbault replied that this is an open discussion point. Trust
  is not just something you rely on; you can put some evaluations in your
  framework as well. Sheffer further asks if the editors thought there’s value
  in separate security and privacy considerations for the resource servers
  draft. Richer believes so - there are some different considerations for each.
  Richer does not want, however, to see a separate security document as was
  done in OAUTH. Pinkas doesn’t believe that the document actually follows RFC
  6973 all that well. He was asked to bring up his concerns on the mailing list.

* Open Issues

  + Symmetric Crypto – should symmetric crypto be completely disallowed? PQC is
  largely symmetric, so disallowing it might be problematic down the line.
  Input on issue #299 is requested.

  + SOLID use cases - this use case from the SOLID community can be divided
  into a couple of different cases, depending on whether the AS or the client
  instance gets the artifacts from the end user extension server. If the client
  does the work, it can preload the information, otherwise it is gated by its
  interaction with the AS.

  + End-user vs. resource owner (RO) – these can have different relationships
  even if they are the same person. Subject information is confusing when the
  RO isn’t the equal to the end user.

  + Generic HTTP access type – the access object’s type field is specific to
  the API being protected. It might make sense to use a generic HTTP type which
  would be applicable to far more APIs without additional definition. If the WG
  chooses to go down this path, where should it be done: gnap-core,
  gnap-resource-server, some other document, or even in some other forum? Is
  the WG interested in this idea?

* What topics to focus on for IETF 112? The editors will have another revision
of the core (and maybe the resource) draft before the meeting. Additional
topics should be submitted to the mailing list for consideration. Pinkas asked
for reconsideration of his end user information proposal in contrast to the
current subject information. Sheffer assumes that the group will iterate on the
security and privacy considerations sections before IETF 112, since there is a
lot of work to do there. Gropper notes that IIW (Internet Identity Workshop)
meets next week and asks that GNAP be well represented there.