Subject: [Txauth] Working group name

From: Yaron Sheffer <[email-masked]>
Date: Fri, 05 Jun 2020 23:35:17 +0300

Thank you to all who participated in the two rounds of name selection. This process has been longer than we ever expected, and I’m glad we can declare consensus now and move forward.

Based on the last two weeks’ worth of discussion, we have rough consensus on a name for the proposed working group:

	GNAP: Grant Negotiation and Authorization Protocol

This decision will now enable our AD to put our charter [1] on the IESG's table, where I hope we will be approved as a working group.

Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late July, either as a BoF or as a newly chartered WG.

Thanks,
	Yaron

[1] https://datatracker.ietf.org/doc/charter-ietf-txauth/

---

From: Tom Jones <[email-masked]>
Date: Fri, 5 Jun 2020 13:59:22 -0700

Before we settle on this name, I must ask if the work group is prepared for
the creation of a negotiation protocol, which as I understand it will
include the client asking for grants, the user responding with their intent
(potentially either can start the flow) and the grant jwt (jose, whatever).
Presumably to complete the lifecycle some means for the user to revoke the
grants and query the grants would also be provided.

That seems like more of an integrated solution than prior work efforts have
involved.
What is the current status of the charter?
Peace ..tom

On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer <[email-masked]> wrote:

> Thank you to all who participated in the two rounds of name selection.
> This process has been longer than we ever expected, and I’m glad we can
> declare consensus now and move forward.
>
> Based on the last two weeks’ worth of discussion, we have rough consensus
> on a name for the proposed working group:
>
> This decision will now enable our AD to put our charter [1] on the IESG's
> table, where I hope we will be approved as a working group.
>
> Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late
> July, either as a BoF or as a newly chartered WG.
>
> Thanks,
>         Yaron
>
>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 5 Jun 2020 15:36:16 -0700

Hi Tom

The charter is here https://datatracker.ietf.org/wg/txauth/about/

As I understand it, one of the items we are standardizing
is negotiation protocol between the client and the server. How the server
gathers consent from the user is currently not in scope, and it is not
clear to me what could be standardized in the experience between the user
and the server that would be in scope for the IETF. Similarly for consent
revocation. Additionally, a user may not be involved in the
negotiation process at all.

ᐧ

On Fri, Jun 5, 2020 at 1:59 PM Tom Jones <[email-masked]>
wrote:

> Before we settle on this name, I must ask if the work group is prepared
> for the creation of a negotiation protocol, which as I understand it will
> That seems like more of an integrated solution than prior work efforts
> have involved.

---

From: Tom Jones <[email-masked]>
Date: Fri, 5 Jun 2020 15:55:02 -0700

if it is to be a negotiation - irrespective of the user's direct
involvement, then then I see this sort of flow
1 cl to as - give me a, b c
2 as to cl - here is a grant to a
3 cl to as - no, i really need b or i can't let you in
4 as to cl - here is a grant to a, b
of course an alternate is that might be
1 cl to as i want a, b, c and b is essential (I know justin hates that -
but california law requires it)

That is what i think negotiation is, or is some other kind of negotiation
imagined

Peace ..tom

On Fri, Jun 5, 2020 at 3:36 PM Dick Hardt <[email-masked]> wrote:

>>> Based on the last two weeks’ worth of discussion, we have rough
>>> consensus on a name for the proposed working group:
>>>
>>> This decision will now enable our AD to put our charter [1] on the
>>> IESG's table, where I hope we will be approved as a working group.
>>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 5 Jun 2020 16:03:16 -0700

Sortof

There are other aspects besides the grant contents that may be negotiated.

In my opinion, I don't see why steps 3 and 4 are needed if in step 1 the
client is clear on what is required, and what is optional.

I do think that the following flow is useful, what I call a multi step
negotiation:

1 Client -> AS give me a
2. AS -> Client here is a = 9
3. Client -> AS I also want x (the value of a determines what else, if
anything the Client may need)
4. AS -> Client x = foo

ᐧ

On Fri, Jun 5, 2020 at 3:55 PM Tom Jones <[email-masked]>
wrote:

>>>> Heads up: we intend to meet in the upcoming all-virtual IETF 108 in
>>>> late July, either as a BoF or as a newly chartered WG.
>>>>
>>>> Thanks,
>>>>         Yaron
>>>>
>>>>

---

From: Justin Richer <[email-masked]>
Date: Sun, 7 Jun 2020 11:48:00 -0400

Hi Tom,

The word “negotiation” in the new name is a synonym of “transaction”[1] in the sense that we’re using it. The negotiation isn’t quite what you’re outlining below, but it does start between the client and the AS. What is really happening is the client is requesting something, and the AS is telling the client what it needs to provide, either directly or through the user, to fulfill that request. So the items below would really go something like:

1: cl to as - give me a, b, c
2: as to cl - to get that, give me x, y, or z (and one or more of these can be “interact with the user” in some way)
3: user to as - I approve a and b but not c
4: as to cl - here’s a token for a and b
5: cl to user - we didn’t get “c” and I can’t do anything for you if you don’t let me have “c’, do you want to try that again?
6: cl to as - give me a, b, c (but I can give you proof that I already got a and b)[2]

So if the client didn’t get “c” but really really needs “c”, that’s an error from the client’s perspective but I don’t see it as an error from the protocol perspective. One of the reasons that the client can’t just mark “c” as “essential” to solve this problem is that the client can’t always know :why: it didn’t get “c” in its ultimate token, and in many cases it can’t do much about it. It could have been the user didn’t approve that specific one. It could have been that the AS didn’t allow this particular client to even ask for it. It could have been that the client didn’t provide the right set of information upfront (device posture or organization affiliation credentials come to mind, which are quite separate from client authentication and one big reason to get away from a “client ID” model, but that’s another point). 

Historically, when we’ve had protocols where the client can mark some claims as “optional” or “essential”, we pretty much always end up with all clients marking things as “essential” when they may or may not be in reality. This makes the protocol break unnecessarily at runtime. OAuth 2’s pattern of the client asking for what it needs and getting what it gets has been shown to be very robust, and I think it’ll be even more important when we’ve got multiple dimensions of access being specified (as per our charter). There’s also a whole other discussion about slitting and directing tokens that this group needs to have. 

So that’s why my stance is that we should let the client ask for what it wants, deal with what it gets, and decide if it needs to bug the user and try again or not. After all, the protocol path needs to account for :error: conditions and not just the happy path, and that is what I think is missing below. I think that (4) in the list below is really unlikely if it’s just the client being able to have some sort of “no really I insist” flag. Why would that flag make the AS change its mind about its auth decision made in (2) in the list below? That decision was made in some other context, and it’s not because the client didn’t ask hard enough.

Additionally, I think it gets really messy really quickly when we start letting the client specify some level of desired-ness or required-ness for the things it’s asking for. We end up with states like “I really want this but I can continue without it by doing something different” or “I’m only asking for this ahead of time but I might not need it until later if at all” or any number of other fuzzy bits in between the “essential/optional” false binary. Therefore I think this protocol should allow exactly one class of resource request :and: make the behavior consistent and predictable across it. The means the ideas of what returns an error, what returns with less than what is asked for, or what other options are at the AS’s disposal and what the client can do with them. I think by having a consistent behavior :and: having the ability to do step-up requests (create a new token request built on an existing one) are going to be key for solving this in a real and interoperable fashion, without making things needlessly complicated in ways that don’t solve our problems.

 — Justin

[1] https://www.thesaurus.com/browse/negotiation?s=t

[2] At least, this is a design feature of the XYZ protocol, and I think it’s important to be able to build requests on top of each other.

> On Jun 5, 2020, at 6:55 PM, Tom Jones <[email-masked]> wrote:
> 
> if it is to be a negotiation - irrespective of the user's direct involvement, then then I see this sort of flow
> 1 cl to as i want a, b, c and b is essential (I know justin hates that - but california law requires it)
> 
> That is what i think negotiation is, or is some other kind of negotiation imagined
> 
> Peace ..tom
> 
> 
> On Fri, Jun 5, 2020 at 3:36 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Tom
> 
> The charter is here https://datatracker..ietf.org/wg/txauth/about/ <https://datatracker.ietf.org/wg/txauth/about/>
> 
> As I understand it, one of the items we are standardizing is negotiation protocol between the client and the server. How the server gathers consent from the user is currently not in scope, and it is not clear to me what could be standardized in the experience between the user and the server that would be in scope for the IETF. Similarly for consent revocation. Additionally, a user may not be involved in the negotiation process at all.
> 
> 
> 
> ᐧ
> 
> On Fri, Jun 5, 2020 at 1:59 PM Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
> Before we settle on this name, I must ask if the work group is prepared for the creation of a negotiation protocol, which as I understand it will include the client asking for grants, the user responding with their intent (potentially either can start the flow) and the grant jwt (jose, whatever). Presumably to complete the lifecycle some means for the user to revoke the grants and query the grants would also be provided.
> 
> That seems like more of an integrated solution than prior work efforts have involved.
> On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
> [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ <https://datatracker.ietf.org/doc/charter-ietf-txauth/>
> 
> 
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> [email-masked]

---

From: Tom Jones <[email-masked]>
Date: Sun, 7 Jun 2020 09:52:34 -0700

I believe what you say is reflectively true. It is, however, now, or soon
to be, illegal. I prefer to be ready for the future, rather than be
surprised by it.

What I have been looking for is something like scope, or purpose, that can
be requested by the client for approval by the user. I suspect that will
only work in constrained federations, like healthcare, where a taxonomy of
purposes can be created.

My needs appear to be out of scope of this committee, so I have left it.

thx ..Tom (mobile)

On Sun, Jun 7, 2020, 8:48 AM Justin Richer <[email-masked]> wrote:

> Hi Tom,
>
> The word “negotiation” in the new name is a synonym of “transaction”[1] in
> the sense that we’re using it. The negotiation isn’t quite what you’re
> outlining below, but it does start between the client and the AS. What is
> really happening is the client is requesting something, and the AS is
> telling the client what it needs to provide, either directly or through the
> user, to fulfill that request. So the items below would really go something
> like:
>
>
> 2: as to cl - to get that, give me x, y, or z (and one or more of these
> can be “interact with the user” in some way)
> 5: cl to user - we didn’t get “c” and I can’t do anything for you if you
> don’t let me have “c’, do you want to try that again?
> So if the client didn’t get “c” but really really needs “c”, that’s an
> error from the client’s perspective but I don’t see it as an error from the
> protocol perspective. One of the reasons that the client can’t just mark
> “c” as “essential” to solve this problem is that the client can’t always
> know :why: it didn’t get “c” in its ultimate token, and in many cases it
> can’t do much about it. It could have been the user didn’t approve that
> specific one. It could have been that the AS didn’t allow this particular
> client to even ask for it. It could have been that the client didn’t
> provide the right set of information upfront (device posture or
> organization affiliation credentials come to mind, which are quite separate
> from client authentication and one big reason to get away from a “client
> ID” model, but that’s another point).
>
> Historically, when we’ve had protocols where the client can mark some
> claims as “optional” or “essential”, we pretty much always end up with all
> clients marking things as “essential” when they may or may not be in
> reality. This makes the protocol break unnecessarily at runtime. OAuth 2’s
> pattern of the client asking for what it needs and getting what it gets has
> been shown to be very robust, and I think it’ll be even more important when
> we’ve got multiple dimensions of access being specified (as per our
> charter). There’s also a whole other discussion about slitting and
> directing tokens that this group needs to have.
>
> So that’s why my stance is that we should let the client ask for what it
> wants, deal with what it gets, and decide if it needs to bug the user and
> try again or not. After all, the protocol path needs to account for :error:
> conditions and not just the happy path, and that is what I think is missing
> below. I think that (4) in the list below is really unlikely if it’s just
> the client being able to have some sort of “no really I insist” flag. Why
> would that flag make the AS change its mind about its auth decision made in
> (2) in the list below? That decision was made in some other context, and
> it’s not because the client didn’t ask hard enough.
>
> Additionally, I think it gets really messy really quickly when we start
> letting the client specify some level of desired-ness or required-ness for
> the things it’s asking for. We end up with states like “I really want this
> but I can continue without it by doing something different” or “I’m only
> asking for this ahead of time but I might not need it until later if at
> all” or any number of other fuzzy bits in between the “essential/optional”
> false binary. Therefore I think this protocol should allow exactly one
> class of resource request :and: make the behavior consistent and
> predictable across it. The means the ideas of what returns an error, what
> returns with less than what is asked for, or what other options are at the
> AS’s disposal and what the client can do with them. I think by having a
> consistent behavior :and: having the ability to do step-up requests (create
> a new token request built on an existing one) are going to be key for
> solving this in a real and interoperable fashion, without making things
> needlessly complicated in ways that don’t solve our problems.
>
>  — Justin
>
> [2] At least, this is a design feature of the XYZ protocol, and I think
> it’s important to be able to build requests on top of each other.
>
>> The charter is here https://datatracker..ietf.org/wg/txauth/about/
>> <https://datatracker.ietf.org/wg/txauth/about/>
>>

---

From: Justin Richer <[email-masked]>
Date: Sun, 7 Jun 2020 19:40:07 +0000

Tom, 

I think that a lot of the constraints that you're describing are going to be specific to the APIbeing protected, or at least the vertical that they exist in. It's important that a general purpose protocol like this allow and enable that kind of constraint without necessarily imposing it on other cases where it doesn't make sense. The kind of essential policy is probably known to the AS and it should be able to apply it to the request as needed. The client should also be able to expect predictable behavior in this case. So to me, it makes more sense that this be in a profile from a group like HEART. 

Healthcare is a vitally important area that this work will be used in, and so I hope that you will continue to join this conversation and contribute your expertise. 

- Justin
________________________________________
From: Tom Jones [[email-masked]]
Sent: Sunday, June 7, 2020 12:52 PM
To: Justin Richer
Cc: Dick Hardt; Yaron Sheffer; [email-masked]
Subject: Re: [Txauth] Working group name

I believe what you say is reflectively true. It is, however, now, or soon to be, illegal. I prefer to be ready for the future, rather than be surprised by it.

What I have been looking for is something like scope, or purpose, that can be requested by the client for approval by the user. I suspect that will only work in constrained federations, like healthcare, where a taxonomy of purposes can be created.

thx ..Tom (mobile)

On Sun, Jun 7, 2020, 8:48 AM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

 — Justin

On Jun 5, 2020, at 6:55 PM, Tom Jones <[email-masked]<mailto:[email-masked]>> wrote:

Peace ..tom

On Fri, Jun 5, 2020 at 3:36 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom

The charter is here https://datatracker..ietf.org/wg/txauth/about/<https://datatracker.ietf.org/wg/txauth/about/>

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=7fac7cf6-dbba-41b9-95ef-f32d1f9d6e2d]ᐧ

On Fri, Jun 5, 2020 at 1:59 PM Tom Jones <[email-masked]<mailto:[email-masked]>> wrote:
Before we settle on this name, I must ask if the work group is prepared for the creation of a negotiation protocol, which as I understand it will include the client asking for grants, the user responding with their intent (potentially either can start the flow) and the grant jwt (jose, whatever). Presumably to complete the lifecycle some means for the user to revoke the grants and query the grants would also be provided.

On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
Thank you to all who participated in the two rounds of name selection. This process has been longer than we ever expected, and I’m glad we can declare consensus now and move forward.

Thanks,
        Yaron

--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 11 Jun 2020 19:08:55 +0000

Hello!

> -----Original Message-----
> From: Txauth <[email-masked]> On Behalf Of Yaron Sheffer
> Sent: Friday, June 5, 2020 4:35 PM
> To: [email-masked]
> Subject: [Txauth] Working group name
> 
> Thank you to all who participated in the two rounds of name selection. This
> process has been longer than we ever expected, and I’m glad we can declare
> consensus now and move forward.
> 

I'm thrilled we've come to conclusion here.  Thanks to all in the community who responded and your overall flexibility in getting to closure on the issue.

I've created a placeholder in the datatracker for it -- https://datatracker.ietf.org/wg/gnap/about/.  While the name of the proposed WG has changed from the BoF, the mailing list name will stay the same, txauth@ietf.  Shortly, there should also be pointer in the datatracker from the txauth bof to gnap as well.

> This decision will now enable our AD to put our charter [1] on the IESG's table,
> where I hope we will be approved as a working group.

I've put the charter on the next IESG telechat, June 25th (https://datatracker.ietf.org/iesg/agenda/documents/).

As a process reminder, after the IESG performs an internal review of this charter, it will out for review by the community, and then back to the IESG for final review.

Regards,
Roman

> Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late July,
> either as a BoF or as a newly chartered WG.
> 
> Thanks,
> 	Yaron
> 
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 11 Jun 2020 15:44:27 -0400

Thank you very much, Roman!

 — Justin

> On Jun 11, 2020, at 3:08 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hello!
> 
> I've created a placeholder in the datatracker for it -- https://datatracker.ietf.org/wg/gnap/about/ <https://datatracker.ietf.org/wg/gnap/about/>.  While the name of the proposed WG has changed from the BoF, the mailing list name will stay the same, txauth@ietf.  Shortly, there should also be pointer in the datatracker from the txauth bof to gnap as well.
> 
> I've put the charter on the next IESG telechat, June 25th (https://datatracker.ietf.org/iesg/agenda/documents/ <https://datatracker.ietf.org/iesg/agenda/documents/>).
>