Subject: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 24 Jun 2020 20:20:24 -0700

Benjamin Kaduk has entered the following ballot position for
charter-ietf-gnap-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-gnap/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

  This group is chartered to develop a fine-grained delegation protocol
  for authorization and API access, as well as requesting and providing
  user identifiers and claims.

nit: this appears to parse as "providing user claims", and I'm not sure what
that means.

  The protocol will decouple the interaction channels, such as the end
  user’s browser [...]

"interaction channels" might be a term of art that needs clarification?

  The client and Authorization Server (AS) will involve a user to make
  an authorization decision as necessary through interaction mechanisms
  indicated by the protocol.

>From a privacy perspective, will all of the information to be made
available from the AS to the RS be visible to the user as they make this
authorization decision?

  The group will define interoperability for this protocol between different
  parties, including
   - client and authorization server;
   - client and resource server; and
   - authorization server and resource server.

[obligatory note that just because we define an AS/RS channel doesn't
mean it will be required to use one at runtime, given the potential
for self-contained tokens?]

  Additionally, the delegation process will allow for:
  [...]

Do all of these need to be fully fleshed out in the main protocol spec,
or could some of them be defered to future extensions?  Some of them
feel much more "core" than others, to me.

  - Support for directed, audience-restricted access tokens

I think we need to clarify what "directed" is intended to mean here (if
it's not just a synonym for "audience-restricted" in which case it
should just be removed).

  - A variety of client applications, including Web, mobile,
    single-page, and interaction-constrained applications

side note: this one feels like it would be easier to phrase as "the WG
will seek to minimize assumptions about the form of client applications,
allowing for [...]"

  - Mechanisms for conveying user, software, organization, and other
    pieces of information used in authorization decisions

nit: the "pieces of information" is in a weird place.  What are "user
pieces of information"?
(Also, this is a somewhat interesting place to put an extension point,
though I concede that there will eventually be need for some kind of
extension here .. it just seems like we should try to make use of this
extension point a rare event.)

  - Optimized inclusion of additional information through the
  delegation process (including identifiers and identity assertions)

This seems pretty open-ended and prone to risky things.  E.g., even just
a setup with multiple identifiers quickly becomes complicated in terms
of being able to make precise statements about what specifically is
being proven, whether there is a guaranteed relationship between the two
(or more) identities in question, etc.; and this point seems even more
open-ended than just that.

  Additionally, the group will provide mechanisms for management of the
  protocol lifecycle including:
  [...]
  - Mechanisms for the AS and RS to communicate the access granted by an
    access token

Maybe I'm just confused, but isn't "the access granted by an access
token" exactly the set of authorizations conveyed by that token, i.e.,
the core point of the protocol?  I'm not sure what kind "protocol
lifecycle management" this item is intending to indicate.

  This group is not chartered to develop extensions to OAuth 2.0, and as
  such will focus on new technological solutions not necessarily
  compatible with OAuth 2.0. Functionality that builds directly on OAuth
  2.0 will be developed in the OAuth Working Group, including
  functionality back-ported from the protocol developed here to OAuth 2.0.

Perhaps s/developed in/directed to/ -- we don't need this WG's charter
to make statements that are more appropriate in the OAuth WG's charter.

  The group is chartered to develop mechanisms for conveying identity
  information within the protocol including identifiers (such as email
  addresses, phone numbers, usernames, and subject identifiers) and
  assertions (such as OpenID Connect ID Tokens, SAML Assertions, and
  Verifiable Credentials). The group is not chartered to develop new
  formats for identifiers or assertions, nor is the group chartered to
  develop schemas for user information, profiles, or other identity
  attributes, unless a viable existing format is not available.

This last bit is a decently sized loophole.  If we leave it out that
would force a recharter for picking up a new format, which might not be
so bad.

  The working group will cooperate and coordinate with other IETF WGs such
  as OAUTH, and work with organizations in the community, such as the
  OpenID, as appropriate.

nit: "organizations in the community" is an unusual phrase; I think
"external organizations" is probably more common.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 25 Jun 2020 13:36:36 +0000

Hi Ben!

A few quick, but incomplete, responses/edits before the telechat.

> -----Original Message-----
> From: Txauth <[email-masked]> On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Wednesday, June 24, 2020 11:20 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01:
> (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> 
> nit: this appears to parse as "providing user claims", and I'm not sure what that
> means.

TODO

> "interaction channels" might be a term of art that needs clarification?

TODO

> available from the AS to the RS be visible to the user as they make this

TODO

> [obligatory note that just because we define an AS/RS channel doesn't mean it
> will be required to use one at runtime, given the potential for self-contained
> tokens?]

Are you thinking that clarification would be explicitly stated?

> Do all of these need to be fully fleshed out in the main protocol spec, or could
> some of them be defered to future extensions?  Some of them feel much more
> "core" than others, to me.

Fair.  IMO, the WG needs to have a discussion about how to appropriately decompose these capabilities, once there is an understood scope.  I'm not sure we need to decide now what capabilities are in the "core" vs. follow-on extensions.

> I think we need to clarify what "directed" is intended to mean here (if it's not
> just a synonym for "audience-restricted" in which case it should just be
> removed).

TODO

> side note: this one feels like it would be easier to phrase as "the WG will seek
> to minimize assumptions about the form of client applications, allowing for
> [...]"

TODO
 
> nit: the "pieces of information" is in a weird place.  What are "user pieces of
> information"?

Editorially, the read should be "user [information], software [information], etc.".

Removed "pieces of".

> (Also, this is a somewhat interesting place to put an extension point, though I
> concede that there will eventually be need for some kind of extension here .. it
> just seems like we should try to make use of this extension point a rare event.)
> 
> This seems pretty open-ended and prone to risky things.  E.g., even just a setup
> with multiple identifiers quickly becomes complicated in terms of being able to
> make precise statements about what specifically is being proven, whether there
> is a guaranteed relationship between the two (or more) identities in question,
> etc.; and this point seems even more open-ended than just that.

So the thinking is to scope down what that "additional information" might be?

> Maybe I'm just confused, but isn't "the access granted by an access token"
> exactly the set of authorizations conveyed by that token, i.e., the core point of
> the protocol?  I'm not sure what kind "protocol lifecycle management" this
> item is intending to indicate.

TODO

> Perhaps s/developed in/directed to/ -- we don't need this WG's charter to make
> statements that are more appropriate in the OAuth WG's charter.

Fixed.

> This last bit is a decently sized loophole.  If we leave it out that would force a
> recharter for picking up a new format, which might not be so bad.

In the consensus building to produce this text, it seemed helpful to be clear on what's in and out.

To be clear, is your concern that the text "... unless a viable existing format is not available" is the loophole?

> nit: "organizations in the community" is an unusual phrase; I think "external
> organizations" is probably more common.

Fixed.  (Was cut-and-pasted from the RATS charter)

Regards,
Roman

---

From: Justin Richer <[email-masked]>
Date: Thu, 25 Jun 2020 15:29:36 -0400

Hi Ben,

Thanks for the thorough read through, as always.

Some of my own thoughts the TODO items inline below.

>> nit: this appears to parse as "providing user claims", and I'm not sure what that

Yes, the is intended to parse as “providing user claims”. The idea here is that the client should be able to send claims that it has to the AS that will identify the user in a fashion that the AS can verify. In these cases, the AS can make a policy decision without directly involving the user for interaction. This is largely a gap in the OAuth 2 world, though the Resource Owner Password grant and the Assertions grant kind go in this direction, but there’s a desire in the community for a general mechanism for doing this. To be clear, GNAP is going to defer the details of these kinds of assertions to other specifications, like W3C’s Verifiable Credentials. 

>> "interaction channels" might be a term of art that needs clarification?

I don’t think it’s a specific term of art. I think we really meant “different ways to interact with the user”. One of OAuth 2’s limitations is that it, for the most part, assumes the user’s in a browser, and the core of the protocol is built around that. One of the goals of GNAP is to get away from that as a base assumption.

>> available from the AS to the RS be visible to the user as they make this

Ultimately I don’t think we can fully specify the AS behavior here, but this is a good pillar for privacy considerations.

> Are you thinking that clarification would be explicitly stated?

Note that a self-contained token is one of the communication channels that the group had in mind for AS/RS. We tried to write the requirements in such a way as to allow for self-contained messages, service-based stuff (like introspection), or even all-in-one-box solutions that don’t need “communication” apart from both reading the same database. This is an architectural pillar borrowed from OAuth 2.

>> just a synonym for "audience-restricted" in which case it should just be

This one is my fault — the concept we’re talking about here is one where the AS can effectively tell the client where and how it should use the token. There are a couple different WG participants who have expressed explicit interest in this, and I’ve started a thread on that topic recently:

https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/

>> to minimize assumptions about the form of client applications, allowing for

That seems reasonable to me, and it goes hand-in-hand with the changes to interaction mentioned above. 

>> item is intending to indicate.

This ties into what’s above: the idea is to have a standard model for what an access token represents, and this says we’re going to standardize ways for the AS and RS to communicate that. This could be inside the token, through an introspection style service, or some other thing we haven’t figured out yet. But the thing is, all of these mechanisms should be communicating the same set of information. This is something the OAuth WG didn’t address, and so we ended up with some disparity in the handful of de-facto access token data models there. The goal was to avoid that.

 — Justin

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jun 2020 12:26:43 -0700

Hi Roman,

Sorry to have let this slip well past the telechat...

> Are you thinking that clarification would be explicitly stated?

I don't think it needs to be, no.

> Fair.  IMO, the WG needs to have a discussion about how to appropriately decompose these capabilities, once there is an understood scope.  I'm not sure we need to decide now what capabilities are i…

Sure.  "Allow for" could be read either way, I suppose...

> So the thinking is to scope down what that "additional information" might be?

That would help some, yes.  If we could phrase things such that there's
only a single entity being describe that would be best, e.g., "information
relating to the identity of the [client/whatever]"

> To be clear, is your concern that the text "... unless a viable existing format is not available" is the loophole?

Right.

> Fixed.  (Was cut-and-pasted from the RATS charter)

Thanks for the updates,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jun 2020 12:36:02 -0700

Hi Justin!

> Yes, the is intended to parse as “providing user claims”. The idea here is that the client should be able to send claims that it has to the AS that will identify the user in a fashion that the AS c…

Let me play this back to check that I've got it right: the idea is that the
client might have some existing assertion or something that is evidence
that the user has already consented to something, and the protocol is going
to include a way for the client to convey this artifact to the AS so that
the AS can validate it and skip bothering the user directly?  I think we'd
probably want some additional adjective here to clarify ("user-consent
claims", "user verification claims", etc.) -- my original best-guess
reading was that this was "user-supplied claims", e.g., "I'd like my token
to include this arbitrary claim I just made up, please".  (The latter's
intermingling of user-supplied and trusted-source data is a recipe for
security issues, of course.)

> I don’t think it’s a specific term of art. I think we really meant “different ways to interact with the user”. One of OAuth 2’s limitations is that it, for the most part, assumes the user’s in a br…

Perhaps "decouple the channels by which the protocol participants
communicate"?

> https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/

I think I read that one :)

Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful
way to describe this?

> This ties into what’s above: the idea is to have a standard model for what an access token represents, and this says we’re going to standardize ways for the AS and RS to communicate that. This coul…

Ah, okay.  So is the key point that these mechanisms/data-models are
"consistent across the entire set of protocol flows"?

Thanks,

Ben

---

From: Justin Richer <[email-masked]>
Date: Tue, 30 Jun 2020 15:59:17 -0400

Hi Ben,

> On Jun 30, 2020, at 3:36 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Justin!
> 

Ah, I see the confusion now; right, the idea is not about the user putting claims into something that the AS echoes back to the client. We want the AS to be able to send stuff back that it knows about the user, but the client should be able to send it to the AS as well. For stuff from the client, there are two categories of information people are interested in: identifiers that aren’t proven yet (so it’s just a hint to the AS about who the client :thinks: the user is, like a username) and provable claim sets that the AS can verify independently (and the protocol doesn’t care how that gets validated). Most likely these latter ones will be formatted as assertions. I didn’t want the charter language to limit the format, but I might be overthinking it. I wanted to make sure the charter captured the intent of user information not being a one-way flow in the protocol. How about this:

	… for authorization, API access, user identifiers, and identity assertions. The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request.

It’s much, much longer, but hopefully it avoids the garden path and hopefully gets at capturing the intent.

> Perhaps "decouple the channels by which the protocol participants

That can work.

> Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful

I think that works, as it’s basically about the AS telling the client what to do next. 

> "consistent across the entire set of protocol flows"?

Yes, exactly. We want the different pieces to have a consistent model, without turning the spec into an “abstract data model” spec itself (because we want it to be a concrete protocol). So how about:

	- Data model for granted access and mechanisms for the AS and RS to communicate the granted access model.

> Ben

Thanks again,
 — Justin

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jun 2020 13:08:48 -0700

Hi Justin,

> It’s much, much longer, but hopefully it avoids the garden path and hopefully gets at capturing the intent.

I think it looks good, thanks.

> 	- Data model for granted access and mechanisms for the AS and RS to communicate the granted access model.

Works for me.

Thanks again!

-Ben