Re: [Txauth] Decoupling consent and authorization

Tom Jones <thomasclinganjones@gmail.com> Mon, 03 August 2020 17:30 UTC

Return-Path: <thomasclinganjones@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 9BE493A0FAB for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 10:30:57 -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 Ee4yONj4Pnz6 for <txauth@ietfa.amsl.com>; Mon, 3 Aug 2020 10:30:55 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 937063A114F for <txauth@ietf.org>; Mon, 3 Aug 2020 10:30:29 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id e11so4301559otk.4 for <txauth@ietf.org>; Mon, 03 Aug 2020 10:30:29 -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=OCrFwou0+bsCEWjUaNZx+H9Q4BaEvf7jPA/HyASm1gE=; b=Ngl0AEDkWeGW4xoJeOccgCLkHMJCYMZyJJyPCd4y+dz0S8s9exHPpqEX4lLQ90EAKT QR920sSaZlpeQM4y33fnwEhl9RLE27B5zzngqAtwlPl7GCpXTB+SIVf9lj87FqCipVgm 7pqjbJ5O8qnVAF4B6yrNIvmam75BwHOXy/psaeombe2TlC8dfl6LbchL1EFGMw8io04Z CC6xH3K8S6FwqEnJxvEfHm0TRTPetZa1XHTpBm6ySQ1FUpjA6iNWB1A9JjUXzRHai1j3 8jXkaxTh7CB7OIjIwKrXmj5lpfaycfmDmb8Mi5mLddkrwrWEc+qSfU0sGnuWnzX0Hl0k pYvQ==
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=OCrFwou0+bsCEWjUaNZx+H9Q4BaEvf7jPA/HyASm1gE=; b=BfAger8x8hdwbmZgkVk0BVLiqrTosTYZZeuwkNfIAAZlp2f1eeSkm/hKGgbsnPcFTX 7fOPu21PI/kh1IBqOTOrmM6aWrQYIIzenkBuVvN+A0y3p0+jLGy8AadHmxsB3V+80FDQ OXJpLyk43BbR32+Oqj6Q2kcRIX03ynpNr+SSdgJ34NUPOYAwlcrjO/CTGRFaqlt5GxSV DihNgMVdi94s7GJfsU2wMRwkrM11FSS8pK8WGfLZJ7lNkzcKqTYvs5oMMW5mzL0xB1Ob +AKC0S2pRzeG+llum7EZElLAr/R8Hkj7SwTB3c9YMzp4dVqy8lqoK6kbMgGaeSdiN3oS qSNg==
X-Gm-Message-State: AOAM53190QNoMt/7YJS/i7pfDA3HkpUjy2MvCYhdGVtdY0zZdRSSCvHN 9K5MqIAFSyt2voODxGbc/ut8RUBtSFBKCLxOnGc=
X-Google-Smtp-Source: ABdhPJzmT7QVJmorzAJ+fTca7WcneprPN3Pdtwy4gGRBVEGmxt5TrI+A1vh1TK6A0+MVhVHapoVUd2DbckXjegfyf0s=
X-Received: by 2002:a9d:a03:: with SMTP id 3mr13943813otg.87.1596475828668; Mon, 03 Aug 2020 10:30:28 -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: Tom Jones <thomasclinganjones@gmail.com>
Date: Mon, 3 Aug 2020 10:30:17 -0700
Message-ID: <CAK2Cwb6s7x6pN2ynf5QQFma3kX_BtNoJCGL+fto=ZWJ0miGPkA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, txauth gnap <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a90d8405abfc7eef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/UaIcA5EtS-MdagW11gQLOOKH-Xg>
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 17:30:58 -0000

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
>