Re: [Txauth] Decoupling consent and authorization

Justin Richer <jricher@mit.edu> Mon, 03 August 2020 15:34 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11D93A0C09 for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 08:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Level:
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7oaS4yUPMpk for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 08:34:17 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB363A0BCF for <txauth@ietf.org>; Mon, 3 Aug 2020 08:33:46 -0700 (PDT)
Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 073FXi5R010991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Aug 2020 11:33:44 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4080BEDB-8B0E-46B2-A5AB-1C416660342D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 3 Aug 2020 11:33:43 -0400
In-Reply-To: <CAM8feuQT6XVDao8VE-ZgJkZwWPaXzVTWWy7SdhjJtBRuVyjwSA@mail.gmail.com>
Cc: txauth@ietf.org
To: Fabien Imbault <fabien.imbault@gmail.com>
References: <CAM8feuQT6XVDao8VE-ZgJkZwWPaXzVTWWy7SdhjJtBRuVyjwSA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/a6kzRj-H0Hd7GRB8cSitTXn5HZM>
Subject: Re: [Txauth] Decoupling consent and authorization
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 15:34:19 -0000

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