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 2D6B73A1066 for <>; Mon, 3 Aug 2020 12:07:05 -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 oPvVqKmIcjYY for <>; Mon, 3 Aug 2020 12:07:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FBFC3A1062 for <>; Mon, 3 Aug 2020 12:07:03 -0700 (PDT)
Received: by with SMTP id t18so32089978ilh.2 for <>; Mon, 03 Aug 2020 12:07:03 -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=ft9PhH62bux+ms7cmLzOHrBVBaxajHPB3ytHTR2N6Tw=; b=KVz7PrU85d4R0H6kJI+OsqoK1f/AgAHB88UZXEpl9WmAh+dePobfCPN45uCFzzJoTy itZ+d0368gCo9c4i+81AQ228Boqcur6iw7jLxPJAHg5r+dFqgnZiNSBcuZMM8oYLkFMq sL2agWlNowHc6O6bt6snBjsbN5NJVX0AheRW3wxpOfwkmTWI9U5lfY3KBwX5pKMxXrJ7 TGqwda7TA+fJWuOmbfnJfaE3QVwQ3ZRa3rQipAcnJWV5nJk8k+PgSxSMyGbPpyTPnHK9 ElgK6RAevhtmjXe4cl6aKnOXRu9iREi5qT7G+rYIHWtntLVXeleZUojtBVj4bAzFKWvo BlBA==
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=ft9PhH62bux+ms7cmLzOHrBVBaxajHPB3ytHTR2N6Tw=; b=tg592RBP3m1RJNNtKfmuw88o/YrZOkswrku8zUtLrt0nJkdK+DTnazkxmb1mUmLCla oP4Yd7ITbsjfKwlmoak+rPUso7eSiqDlsuD0GR6ueqRXp644+6S+PJeMe7uKX4YhQu/p 3UsMN+f5bkMWn2aJ47+LNmzldxWDO5A/+ackrR8UpwIoKB0CAbosGokWkrCMd/bQO7Gv NRg3p3Wl3Ew8Ia17eUvwsg7s0KNho60pm0JQyyoLmV7Yj7BAWAdKUiuX4Ep3kWbfCxfN dyVAR4JPY3xB5j2Tj1tfS3WJEmdkFfuLL2PRCE0zMb7RttUXyzQp7mD9zJHqhwFuqMqG z6Hg==
X-Gm-Message-State: AOAM533sAx0q09wqx9p9GEM/Nlt49axrQZkFYU+vdxohp/EKfjdqZMoY GuF6RsxCKKdUDWxSBtHn0MXpxc/QCItE6cciaN4I17EC
X-Google-Smtp-Source: ABdhPJyMG+7o3UqjXnFXsOoyC22Pg6oQlzP8m8cihLnPw/gps+FmwLDOBEQs5yO1bUb5Q5So17G2mnC1+wD2QNn3IqM=
X-Received: by 2002:a05:6e02:8:: with SMTP id h8mr846091ilr.188.1596481622555; Mon, 03 Aug 2020 12:07:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Mon, 3 Aug 2020 21:06:43 +0200
Message-ID: <>
To: Dick Hardt <>
Cc: GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="00000000000000c0e505abfdd8f9"
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:05 -0000

Hi Dick,

Yes correct. For 2 reasons : it's a pain (not very secure, not very
scalable) to have to mix front end and back end + it started as an exercise
following discussions with Denis (consent made by Client).

In the context, I meant Client. The flow could be started by a request from
the Client, just like it is currently in standard XYZ, but with an
additional optional parameter in case it wishes to use a specific interact
server (instead of the one embedded or chosen by the AS).

And then there's really the Agent, which is indeed different from the
Client, you're right.


On Mon, Aug 3, 2020 at 7:28 PM Dick Hardt <> wrote:

> Hi Fabien
> If I understand this correctly, you are factoring out the user
> authentication and consent from the AS issuing the access token. Correct?
> wrt. "the interaction handled by a Client endpoint" .. I think there is a
> conflation of the term Client ... software that can authenticate the user
> and act in the user's interest is NOT the GNAP Client. Perhaps Agent? ...
> it is a different component from the Client.
> On Mon, Aug 3, 2020 at 4: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