Re: [Txauth] Decoupling consent and authorization

Fabien Imbault <fabien.imbault@gmail.com> Tue, 04 August 2020 12: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 59D143A0A96 for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 05:23:30 -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 5F8KBn-ZcBur for <txauth@ietfa.amsl.com>; Tue, 4 Aug 2020 05:23:28 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4AC7A3A0A93 for <txauth@ietf.org>; Tue, 4 Aug 2020 05:23:28 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id g19so29880796ioh.8 for <txauth@ietf.org>; Tue, 04 Aug 2020 05:23:28 -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=fwKqKFa3zLCQCzfZqc2xqvhtZma25e5NJtFZDJdRtM4=; b=npw677c+qFkQ97T+0GTcJembE0UsGYBTs1Vaqu1I3D33rRAYDkJFH0N3sgddpEPN35 y0UTRGai3xecHa+PrVUcPGeoxPga+I1tq9DAXJIQah2sy85wkuHDz+Zmn2GzRKg1pKJl MYum94s0SWmiiYN2BawCuJaBI8xZx0fCHTWih49PWMrE6HW+0SFBhN38HICq2SJZYcP2 UydQrAeR/ydwwU938DcLVhnaivJg8qKmwDXjqJESyfvx9WVpEMZ74m/yVIOW2Snoyc57 hjHsGjayLviPAAG+r+JApShIMC7MKIEUC9u+BAJej6G6yY1vTAw+8yzE/ShZcndl8q3+ jpVw==
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=fwKqKFa3zLCQCzfZqc2xqvhtZma25e5NJtFZDJdRtM4=; b=Fnf5qIX/78aUPQOSoke+oPFoud7BzAUzblsoNR+fqlzmf3SCGCqlkApdzj3oODI5SL pC9PguzE3+RyaoyEzXbaQSGNlhTxT9g+RfV6F/65lE5t3n/ub9N/8RwO78RSbpAB0LaE 6OUuhWUNHEYNzfxqcfWVqbdZF/Qaz+ySAmdr8JZxMyiLN8B2Q+pLDfvyNyS4hiuIlPi2 QlA5SLVrn646vC9ClRgj/RJk9vPJIBS++YPMGJUJdO+0NgT3AFgC2KgzZaaWDlDa9EE3 SboSZz9E70sHAaXvwrqbKDtSnQbDPo/RnZrKCKCJh/Vx/Rr9cLOqhn3RK/pPc975MKJv 2Hyw==
X-Gm-Message-State: AOAM5309SFCDCJQQD4GvibYjp9eOaYyslNhJ5RAmhKRAGlfdPRK+rIre KWB8H2rD+gcZeoYJKNyiJYVSqfaC6wjCJ3lxIKscm2zi
X-Google-Smtp-Source: ABdhPJxlDO/s8NRN4SlwnQVNhBOBxLtszYJcNuvjvsUMsOUlvzBBH3E2t7a3cUNstqFr8W1bO9GUYELQANVU4Jagtes=
X-Received: by 2002:a5d:841a:: with SMTP id i26mr4862125ion.144.1596543807541; Tue, 04 Aug 2020 05:23:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAM8feuQT6XVDao8VE-ZgJkZwWPaXzVTWWy7SdhjJtBRuVyjwSA@mail.gmail.com> <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> <CAM8feuQyPNVfNW12_ns2q2EBzGabYR7iKHBn0--MJuvf0HwH0w@mail.gmail.com> <085908D8-8D48-4BE5-818A-B5F1232950BA@mit.edu>
In-Reply-To: <085908D8-8D48-4BE5-818A-B5F1232950BA@mit.edu>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Tue, 4 Aug 2020 14:23:15 +0200
Message-ID: <CAM8feuRbrzWPEGVFhga222d+XaJ5vawVUvKYMFMp3biuL9dMgg@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008454f005ac0c523c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/gkAr8WDdf1bQeTDPw96x_oUzN6Y>
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: Tue, 04 Aug 2020 12:23:30 -0000

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

Cheers

Fabien

On Mon, Aug 3, 2020 at 8:27 PM Justin Richer <jricher@mit.edu> 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:
>
> https://github.com/ietf-wg-gnap/general/wiki/Use-Cases
>
>  — Justin
>
> On Aug 3, 2020, at 12:22 PM, Fabien Imbault <fabien.imbault@gmail.com>
> 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 <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
>>
>>
>>
>