Re: [Txauth] Decoupling consent and authorization

Fabien Imbault <> Tue, 04 August 2020 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59D143A0A96 for <>; Tue, 4 Aug 2020 05:23:30 -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 5F8KBn-ZcBur for <>; Tue, 4 Aug 2020 05:23:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AC7A3A0A93 for <>; Tue, 4 Aug 2020 05:23:28 -0700 (PDT)
Received: by with SMTP id g19so29880796ioh.8 for <>; Tue, 04 Aug 2020 05:23:28 -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=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;; 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: <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Tue, 4 Aug 2020 14:23:15 +0200
Message-ID: <>
To: Justin Richer <>
Cc: GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000008454f005ac0c523c"
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: Tue, 04 Aug 2020 12:23:30 -0000

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



On Mon, Aug 3, 2020 at 8:27 PM Justin Richer <> 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:
>  — Justin
> On Aug 3, 2020, at 12:22 PM, Fabien Imbault <>
> 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 <> 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