Subject: [Txauth] Decoupling consent and authorization

From: Fabien Imbault <[email-masked]>
Date: Mon, 3 Aug 2020 13:15:27 +0200

Hello,

This is a new thread.

I have just published a proof of concept that separates the interaction
from the rest of the AS. The goal is to open up the door to a privacy
preserving flow such as the one suggested by Denis (the interaction may be
handled by a Client endpoint, if it wishes), as well as to optimize the
implementation to each concern (UX for consent vs authorization flows).

Note that it ends up being an implementation detail as far as the Client is
concerned, as the core request/response format wasn't changed from the
original XYZ protocol.

The code and documentation is available publicly at:
https://github.com/acertio/mvp_gnap_interact

The flow is sketched and explained at
https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#process

Let me know what you think.

Cheers

Fabien

---

From: Justin Richer <[email-masked]>
Date: Mon, 3 Aug 2020 11:33:43 -0400

Fabien,

Thanks for writing this up, this is interesting work! So if I’m reading this correctly, the “interact_ref” portion is now also used to connect the consent component with the AS, right? I like how it folds in the verification of components with a really simple calculation, and that allows the steps to be chained together. I really like that the extra steps don’t affect what the client needs to know or what it has to do, so a server could deploy with or without this and not change client behavior. 

I have a couple questions about how you think this might play out in a deployment:

1) Do you think the interact server would sign its request to the AS in 7? Since it’s a direct HTTP POST this should be able to use any of the signing/proof mechanisms that the rest of GNAP would use.
2) How does the interaction server get information about the consent being gathered, in order to display the appropriate UI to the user? This seems like it could be part of the exchange in 7/8 but I’m not sure what the details would look like, any thoughts there?
3) How does the interaction server communicate the results of the consent back to the AS? It seems like that would require a second round trip.

I’m particularly interested in this idea because it could allow standardization of something that OAuth is really bad at: interaction through components that are not accessed via web browser. Think of it like this: you’ve got an AS that handles the tokens and managing state and all that, but you’ve got an on-device app to handle the actual consent and user interaction portions. Previously, I’d hand-waved that they’d talk to each other somehow, but this approach could give us a way for that on-device app to talk back to the AS, get the information it needs to draw a UI, and continue the request without it needing to have a full view of everything back at the server.

 — Justin

> On Aug 3, 2020, at 7:15 AM, Fabien Imbault <[email-masked]> wrote:
> 
> Hello, 
> 
> This is a new thread. 
> 
> I have just published a proof of concept that separates the interaction from the rest of the AS. The goal is to open up the door to a privacy preserving flow such as the one suggested by Denis (the interaction may be handled by a Client endpoint, if it wishes), as well as to optimize the implementation to each concern (UX for consent vs authorization flows). 
> 
> Note that it ends up being an implementation detail as far as the Client is concerned, as the core request/response format wasn't changed from the original XYZ protocol.
> 
> https://github.com/acertio/mvp_gnap_interact <https://github.com/acertio/mvp_gnap_interact>
> 
> The flow is sketched and explained at https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#process <https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#process>
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 3 Aug 2020 18:22:54 +0200

Hi Justin,

Thanks for your feedback. The point is indeed to evaluate whether this
opens up new capabilities.

A preliminary response:

1) yes, we would have to sign the request, by any mean supported by GNAP.
2) right now it's pretty much hardcoded, which would be fine in some cases;
but more generally the way that requirement is gathered into GNAP still
needs to be worked out: probably the Client needs to do a first call to the
RS before. This is important to know if we want to keep it as an
implementation detail, that the Client may not even care about. Could be
part of the request (the simplest, but is it fine with privacy requirement
if we need to route through the AS?) or we could have continuation Tx
specific to the consent component.
3) we have a very basic example (global yes/no) in which we didn't have to
care (the flow either continues or stops), but indeed, we would need a
second complete HTTP roundtrip (in a simple implementation) or allow more
advanced communication patterns to reduce roundtrips (we have more
flexibility since the Client in not in the loop here). There's currently a
lot of work on 0-RTT in workgroups such as DIDComm and QUIC that we could
leverage for some high perf scenarios.

I'll work on a more advanced proposal for these, still a lot of work in
order to keep things simple and stupid ;-)

Cheers

Fabien

On Mon, Aug 3, 2020 at 5:33 PM Justin Richer <[email-masked]> wrote:

> Fabien,
>
> Thanks for writing this up, this is interesting work! So if I’m reading
> this correctly, the “interact_ref” portion is now also used to connect the
> consent component with the AS, right? I like how it folds in the
> verification of components with a really simple calculation, and that
> allows the steps to be chained together. I really like that the extra steps
> don’t affect what the client needs to know or what it has to do, so a
> server could deploy with or without this and not change client behavior.
>
> 1) Do you think the interact server would sign its request to the AS in 7?
> Since it’s a direct HTTP POST this should be able to use any of the
> signing/proof mechanisms that the rest of GNAP would use.
> 2) How does the interaction server get information about the consent being
> gathered, in order to display the appropriate UI to the user? This seems
> like it could be part of the exchange in 7/8 but I’m not sure what the
> details would look like, any thoughts there?
> 3) How does the interaction server communicate the results of the consent
> back to the AS? It seems like that would require a second round trip.
>
>
> I’m particularly interested in this idea because it could allow
> standardization of something that OAuth is really bad at: interaction
> through components that are not accessed via web browser. Think of it like
> this: you’ve got an AS that handles the tokens and managing state and all
> that, but you’ve got an on-device app to handle the actual consent and user
> interaction portions. Previously, I’d hand-waved that they’d talk to each
> other somehow, but this approach could give us a way for that on-device app
> to talk back to the AS, get the information it needs to draw a UI, and
> continue the request without it needing to have a full view of everything
> back at the server.
>
>  — Justin
>
> Note that it ends up being an implementation detail as far as the Client
> is concerned, as the core request/response format wasn't changed from the
> original XYZ protocol.
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 3 Aug 2020 10:27:31 -0700

Hi Fabien

If I understand this correctly, you are factoring out the user
authentication and consent from the AS issuing the access token. Correct?

wrt. "the interaction handled by a Client endpoint" .. I think there is a
conflation of the term Client ... software that can authenticate the user
and act in the user's interest is NOT the GNAP Client. Perhaps Agent? ...
it is a different component from the Client.

---

From: Tom Jones <[email-masked]>
Date: Mon, 3 Aug 2020 10:30:17 -0700

Here is an alternative to that consisting of two token "niblets",
essentially signed and encoded tokens that are designed to be embedded in
an az token. These can be viewed as lite-weight VCs.
https://wiki.idesg.org/wiki/index.php/Delegation

https://wiki.idesg.org/wiki/index.php/Delegation

and the consent to create binding which can be viewed as the user doing
dynamic registration.
https://wiki.idesg.org/wiki/index.php/Consent_to_Create_Binding

These are IMHO necessary to do distributed identity.

thx ..Tom (mobile)

---

From: Justin Richer <[email-masked]>
Date: Mon, 3 Aug 2020 14:27:04 -0400

Thank you for the clarifications! Yes, I agree that with these simplifications the protocol collapses quite nicely like this. I wonder if this could be an area where GNAP could provide support for those that need the extra connections but stay out of the way of those that don’t — like how token introspection allows a runtime query of a token’s status and capabilities, but nobody’s suggesting it be mandated for all systems (for what I hope are obvious reasons!). Then perhaps just like introspection this could be an “internal protocol” that interested AS’s would use, but whether or not it got used wouldn’t affect the outside of the protocol. This kind of functional layering is a really good design goal.

Another thing, this makes me wonder if we should in fact split up the role of what’s classically been the AS into two functional roles. One part talks to the client, the other part interacts with the user (interaction server?). The connection between these components is what this “internal protocol” would define, though there would be other ways to handle it if you wanted to, just like with introspection.

If you haven’t done so yet, I would recommend that you write up some pages in the Use Cases wiki describing the kinds of things you’re after:

https://github.com/ietf-wg-gnap/general/wiki/Use-Cases

 — Justin

> On Aug 3, 2020, at 12:22 PM, Fabien Imbault <[email-masked]> wrote:
> 
> Hi Justin, 
> 
> Thanks for your feedback. The point is indeed to evaluate whether this opens up new capabilities.
> 
> A preliminary response: 
> 
> 2) right now it's pretty much hardcoded, which would be fine in some cases; but more generally the way that requirement is gathered into GNAP still needs to be worked out: probably the Client needs to do a first call to the RS before. This is important to know if we want to keep it as an implementation detail, that the Client may not even care about. Could be part of the request (the simplest, but is it fine with privacy requirement if we need to route through the AS?) or we could have continuation Tx specific to the consent component. 
> 3) we have a very basic example (global yes/no) in which we didn't have to care (the flow either continues or stops), but indeed, we would need a second complete HTTP roundtrip (in a simple implementation) or allow more advanced communication patterns to reduce roundtrips (we have more flexibility since the Client in not in the loop here). There's currently a lot of work on 0-RTT in workgroups such as DIDComm and QUIC that we could leverage for some high perf scenarios.  
> 
> I'll work on a more advanced proposal for these, still a lot of work in order to keep things simple and stupid ;-)
> 
> Cheers
> 
> Fabien
> 
> On Mon, Aug 3, 2020 at 5:33 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Fabien,
> 
>> On Aug 3, 2020, at 7:15 AM, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello, 
>> 
>> This is a new thread. 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 3 Aug 2020 21:06:43 +0200

Hi Dick,

Yes correct. For 2 reasons : it's a pain (not very secure, not very
scalable) to have to mix front end and back end + it started as an exercise
following discussions with Denis (consent made by Client).

In the context, I meant Client. The flow could be started by a request from
the Client, just like it is currently in standard XYZ, but with an
additional optional parameter in case it wishes to use a specific interact
server (instead of the one embedded or chosen by the AS).

And then there's really the Agent, which is indeed different from the
Client, you're right.

Fabien

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 3 Aug 2020 21:07:26 +0200

Thanks for the references Tom, will definitely check them out.
Fabien

On Mon, Aug 3, 2020 at 7:30 PM Tom Jones <[email-masked]>
wrote:

>> 1) Do you think the interact server would sign its request to the AS in
>> 7? Since it’s a direct HTTP POST this should be able to use any of the
>> 2) How does the interaction server get information about the consent
>> being gathered, in order to display the appropriate UI to the user? This
>> seems like it could be part of the exchange in 7/8 but I’m not sure what
>> the details would look like, any thoughts there?

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 4 Aug 2020 14:23:15 +0200

Thanks Justin. I have written a use case for that.

Cheers

Fabien

On Mon, Aug 3, 2020 at 8:27 PM Justin Richer <[email-masked]> wrote:

> Thank you for the clarifications! Yes, I agree that with these
> simplifications the protocol collapses quite nicely like this. I wonder if
> this could be an area where GNAP could provide support for those that need
> the extra connections but stay out of the way of those that don’t — like
> how token introspection allows a runtime query of a token’s status and
> capabilities, but nobody’s suggesting it be mandated for all systems (for
> what I hope are obvious reasons!). Then perhaps just like introspection
> this could be an “internal protocol” that interested AS’s would use, but
> whether or not it got used wouldn’t affect the outside of the protocol.
> This kind of functional layering is a really good design goal.
>
> Another thing, this makes me wonder if we should in fact split up the role
> of what’s classically been the AS into two functional roles. One part talks
> to the client, the other part interacts with the user (interaction
> server?). The connection between these components is what this “internal
> protocol” would define, though there would be other ways to handle it if
> you wanted to, just like with introspection.
>
> If you haven’t done so yet, I would recommend that you write up some pages
> in the Use Cases wiki describing the kinds of things you’re after:
>
> 2) right now it's pretty much hardcoded, which would be fine in some
> cases; but more generally the way that requirement is gathered into GNAP
> still needs to be worked out: probably the Client needs to do a first call
> to the RS before. This is important to know if we want to keep it as an

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 04 Aug 2020 15:29:12 +0300

And to those who haven’t been following, there’s already a long list of use cases on our wiki [1]. Thanks to all who contributed!

                Yaron

[1] https://github.com/ietf-wg-gnap/general/wiki/Use-Cases 

From: Txauth <[email-masked]> on behalf of Fabien Imbault <[email-masked]>
Date: Tuesday, August 4, 2020 at 15:23
To: Justin Richer <[email-masked]>
Cc: GNAP Mailing List <[email-masked]>
Subject: Re: [Txauth] Decoupling consent and authorization

Cheers

Fabien

 — Justin

Hi Justin, 

A preliminary response: 

Cheers

Fabien

Fabien,

 

 — Justin

Hello, 

This is a new thread. 

The flow is sketched and explained at https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#process

Cheers

Fabien

 

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