Re: [Txauth] Decoupling consent and authorization

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 <fabien.imbault@gmail.com> 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
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth