Re: [Txauth] Decoupling consent and authorization

Fabien Imbault <fabien.imbault@gmail.com> Mon, 03 August 2020 19:07 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 B614B3A1066 for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 12:07:47 -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 hrwSLJZH60GW for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 12:07:45 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 B33C73A1062 for <txauth@ietf.org>; Mon, 3 Aug 2020 12:07:45 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id z17so16962020ill.6 for <txauth@ietf.org>; Mon, 03 Aug 2020 12:07:45 -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=5m/p2rVRhmdSREFlnnb4NpJcFSkztjmoL4q/lzm+SZw=; b=Olb6nbAqa900AG7EePz3ExVPldIPmDPb2dQ++rJcEA/QKzjIz6vPua1HNuhXrcjuQS qCUUDKA/B3DcClY8U1LC0SoeOc5T4ekggBc9mYB06tT4fFody+VswLUuc4YYnx8N237G 7q1jBlkBkFoKJi69fz3YiJIi2X28jL2Zo250ClfBuRb9qBnI2EkWjevNiCEiP7YtuAfz v/hBx9Z9DwLoLuai/mVqGv2Hp81yonI5puGDPJxRnWKjxfEVZ51I/P7+Oz49Ih+hsi3q GI8+4txL4Upd2OoaeoI2bv+iGbSMrCafDTYO2H8w8sw/Ham2ew4mFxh4Hfc4FGWvGLGf GPVA==
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=5m/p2rVRhmdSREFlnnb4NpJcFSkztjmoL4q/lzm+SZw=; b=VyP3Gi/A+D9rgzNIIJ0eVIdW4xnvERfXKijEnQnfiyUXFuWm6xiSEVEYJNF3T6g3iQ SPWN5p27SwpMiLzhD7PnuusMmpmc6JIEXyVgSLQBMkNip9Nh3pbouyl8G7c8n5wrPpSh +14BBa0O6UwRcMYnoLMDEuAUJqVuzvXsESsGf/vtAJseiV0Ge+neL+pzPP0SF5VuOf2s 3tsMExgtuUyXamYMis0g2CTZvpAd9KHbXat91gz/ZeePye9alilqkvhGXBAQz3etZCgB VWbuB8mGQlUIgYp+fotg5TfzJiZamj4FRMnxP2EigjxGiEnxBFXAsQxCkresLnsnd+nV fN1Q==
X-Gm-Message-State: AOAM532hz0pJ4xELmZGA+G4zN0vnzSSqEzGOM5idL/RgMVCjqLpypMVV Wka9+p+uAj5rgkU5qd5r6SUQDkn2+Mv0ZWFDQJ0=
X-Google-Smtp-Source: ABdhPJzpPd6VNh68y4BQjop09DPmTkDGV8RUhrZh7WAQp+QO0CocbJCGqiDxhBHchtb0jg626Q5XtSWiidA7PhW5x4s=
X-Received: by 2002:a92:35c8:: with SMTP id c69mr930306ilf.289.1596481665035; Mon, 03 Aug 2020 12:07:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAM8feuQT6XVDao8VE-ZgJkZwWPaXzVTWWy7SdhjJtBRuVyjwSA@mail.gmail.com> <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> <CAK2Cwb6s7x6pN2ynf5QQFma3kX_BtNoJCGL+fto=ZWJ0miGPkA@mail.gmail.com>
In-Reply-To: <CAK2Cwb6s7x6pN2ynf5QQFma3kX_BtNoJCGL+fto=ZWJ0miGPkA@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Mon, 3 Aug 2020 21:07:26 +0200
Message-ID: <CAM8feuSPvBZ=QiL0Zk1_-G52igyEnw7LNa=bKEDrjACHXiA_=g@mail.gmail.com>
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, txauth gnap <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000089024805abfdda22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/qI4dBoVe-4tSgip99sjkHnFS4Wo>
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 19:07:48 -0000

Thanks for the references Tom, will definitely check them out.
Fabien

On Mon, Aug 3, 2020 at 7:30 PM Tom Jones <thomasclinganjones@gmail.com>
wrote:

> Here is an alternative to that consisting of two token "niblets",
> essentially signed and encoded tokens that are designed to be embedded in
> an az token. These can be viewed as lite-weight VCs.
> https://wiki.idesg.org/wiki/index.php/Delegation
>
> https://wiki.idesg.org/wiki/index.php/Delegation
>
> and the consent to create binding which can be viewed as the user doing
> dynamic registration.
> https://wiki.idesg.org/wiki/index.php/Consent_to_Create_Binding
>
> These are IMHO necessary to do distributed identity.
>
> thx ..Tom (mobile)
>
> On Mon, Aug 3, 2020, 8:34 AM 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
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>