Re: [Txauth] Decoupling consent and authorization

Fabien Imbault <fabien.imbault@gmail.com> Mon, 03 August 2020 16:23 UTC

Return-Path: <fabien.imbault@gmail.com>
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 193143A0F35 for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 09:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Kw-xafK_wNdv for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 09:23:06 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE003A0F31 for <txauth@ietf.org>; Mon, 3 Aug 2020 09:23:06 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id u126so1838423iod.12 for <txauth@ietf.org>; Mon, 03 Aug 2020 09:23:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dmi5UMuGhhb+z1WT6R6he8vy17s0XAQmC+WA4CvkZk0=; b=doj2BYd/Y5nyhlcbCSGNelBrakR0bSSRVq6fri9NDWz7dRDXY/jCYllQGmj7Dt/l3k mX9Or/Uia8rkqLyblnVNDmZ3rsaTFyAIF10J2Rek4kk3NQkzVQtQvrBJOib6kwrc7UgD o/wO4+C8Ka3/FUjJhIsRn46d7SWr8wr3HJhDcwPYq3i5jxp1vYS0dwhSkCzLZuERrMay lkSuJ1UY3oy4YoFIABhZImocZGRkV86qM8nn4GUiHPCnR1058MmVey1DqgPwrQQDFVAq iC//Ijv8rooyFkPPq7id8D/2OMGYtXUlddUQ1S3YYILT7evkHNNQ+oebX+qjFf1/YIGr xVsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dmi5UMuGhhb+z1WT6R6he8vy17s0XAQmC+WA4CvkZk0=; b=qfwMBDHTZka3qL8MmjoF4F0r7H4GMuewJw6nXRSH/0uBKE32XfBxxXOU3gOAQK+Rsr AeoWwdXdKzhTjW89z2fivUcJHLd8zR25vTaFyj+8p8sItJHGpyYP/fJuEZWav5+WCF3E KhH8dSCixXLSEek9NgBSu1Fa1gBE2Umtu1bSsQasQdDh1q3/DaoSZBtQfy+uIdiM9VAn sLuwyJzsjA9xVAwtxiYdtomW04iFFD4sJyjL6mFa81MXWXoV3OfR8eannygmwpDV0Q/r 42F4S42Y7xCP966TLJoNGzZvcfjRo0/CiryMc6RrO6hBA/3oMvR+SYly6mrj7c9eQtJr dmAQ==
X-Gm-Message-State: AOAM532Idp+qFGX8TSnyFwqo5q8OEDcAGw2scI7M1PnGFzR+B7+uFp8e tya8xSqyvAFVRexkhir/IGykC9rcokO/wMwTkaCuUASq
X-Google-Smtp-Source: ABdhPJz3ptlV8wv3qRvMtA7nWPyguw+mgKRblKFCBVpk3k4iJaZolhhDtQ7SVeEQQsqD/y2Hf5aM4rhggLevfvM+gO4=
X-Received: by 2002:a05:6638:d46:: with SMTP id d6mr477667jak.124.1596471785557; Mon, 03 Aug 2020 09:23:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAM8feuQT6XVDao8VE-ZgJkZwWPaXzVTWWy7SdhjJtBRuVyjwSA@mail.gmail.com> <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu>
In-Reply-To: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Mon, 3 Aug 2020 18:22:54 +0200
Message-ID: <CAM8feuQyPNVfNW12_ns2q2EBzGabYR7iKHBn0--MJuvf0HwH0w@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ac118005abfb8db6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/OcVJxiGE6fqGbni6PmKH1qFxxJ0>
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 16:23:08 -0000

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 <jricher@mit.edu> 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 <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
>
> 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
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>