Re: [Txauth] Decoupling consent and authorization

[Justin Richer <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> 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. 
> 
> 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 <[e-mail] <mailto:[e-mail]>> 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.
>> 
>> The code and documentation is available publicly at:
>> 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>
>> 
>> Let me know what you think.
>> 
>> Cheers
>> 
>> Fabien
>> 
>> -- 
>> Txauth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>