Re: [Txauth] Decoupling consent and authorization

Fabien Imbault <> Mon, 03 August 2020 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B614B3A1066 for <>; Mon, 3 Aug 2020 12:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hrwSLJZH60GW for <>; Mon, 3 Aug 2020 12:07:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B33C73A1062 for <>; Mon, 3 Aug 2020 12:07:45 -0700 (PDT)
Received: by with SMTP id z17so16962020ill.6 for <>; Mon, 03 Aug 2020 12:07:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Mon, 3 Aug 2020 21:07:26 +0200
Message-ID: <>
To: Tom Jones <>
Cc: Justin Richer <>, txauth gnap <>
Content-Type: multipart/alternative; boundary="00000000000089024805abfdda22"
Archived-At: <>
Subject: Re: [Txauth] Decoupling consent and authorization
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Aug 2020 19:07:48 -0000

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

On Mon, Aug 3, 2020 at 7:30 PM Tom Jones <>

> 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.
> and the consent to create binding which can be viewed as the user doing
> dynamic registration.
> These are IMHO necessary to do distributed identity.
> thx ..Tom (mobile)
> On Mon, Aug 3, 2020, 8:34 AM Justin Richer <> 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 <>
>> 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:
>> The flow is sketched and explained at
>> Let me know what you think.
>> Cheers
>> Fabien
>> --
>> Txauth mailing list
>> --
>> Txauth mailing list