Re: [Txauth] Decoupling consent and authorization

Yaron Sheffer <> Tue, 04 August 2020 12:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADEE63A0A9B for <>; Tue, 4 Aug 2020 05:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.377
X-Spam-Level: *
X-Spam-Status: No, score=1.377 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, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QB1XX3wku-VZ for <>; Tue, 4 Aug 2020 05:29:16 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52DEF3A0475 for <>; Tue, 4 Aug 2020 05:29:16 -0700 (PDT)
Received: by with SMTP id k20so2716221wmi.5 for <>; Tue, 04 Aug 2020 05:29:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=clP2XL80jT6hemIIr4xCIkjiKb7Y3huBg2Wq5EfVjGA=; b=E7nJOaSU/aPsZ62U7f6lRe9N0WcvX9zRyCCv++7z/8e+u3yzkpb/bONeFD+pg+yiGY /zMY5cCRgfBgd9EP64/zUp7tn4xYxSIy/cDb62p8wRJCnJjQVRZWvr+sZr9Kn1eIwfUE gRRH+PIFCtZbEH06cn8yO6LNodtfZT/0vGfb0e+tMXIQDdo/h69tzV0WYhsDIl94n+T6 iaMMYKrhNGudBh4n1no1Bm+4pg0XO6fK5JwtgtNlgqn0IK8esWL9xjbxzN4+MjSQg4s6 CJFvmbZ6TFg5w9oDp5eJtaIEOXIufxofvrxmINk3vBSRkwLy15b8cI7l1tvTc+wg5+yo HD2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=clP2XL80jT6hemIIr4xCIkjiKb7Y3huBg2Wq5EfVjGA=; b=J3J0lYxwuQWHOeaIaaiIRI6IQQ0Qc8VFESiW8LRjLlWkiQ7mwdsMWan+t9vniajJAX fU93C16VkuEgvyZzrsQfjodwI58W6NAhxExOuSW8qPh/KNxzCSDIBtYVgbeQNkq+oPIf DWbUWBWMxnDmSGZNb4SoDJqpZ65eqU+ZteCC8jPcd7Xb6SA1+Yhh+IF22RQFPqHtE0Yr DhpugNcYyGyR2CHbcW6qI51kGetYHmdZbh39hBjmSF4bF+61DrXFBGtkhowlzQkmV9Us LEiqNTEh4bIKCX2qPhHtoUGBJonvXdkJ3C1GlcPQ5NdmDclbrlkBpITSSufBgg9+d22G r3cQ==
X-Gm-Message-State: AOAM53195ti/QxRyFmUPdT3NnzXDv/E7pfsobD22Bdc+4fbYg4OByGFF UwMwTxMWa71MCeTH90RVwBk=
X-Google-Smtp-Source: ABdhPJx95+Dp/hSCAWVEjYroTchS3xeyvBFmpqFOQhm0VpXiDBUB5miebEyDTSUNX4bKfEB7KcRzKQ==
X-Received: by 2002:a05:600c:2215:: with SMTP id z21mr4166163wml.159.1596544154778; Tue, 04 Aug 2020 05:29:14 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id i4sm30056374wrw.26.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2020 05:29:14 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.39.20071300
Date: Tue, 04 Aug 2020 15:29:12 +0300
From: Yaron Sheffer <>
To: Fabien Imbault <>, Justin Richer <>
CC: GNAP Mailing List <>
Message-ID: <>
Thread-Topic: [Txauth] Decoupling consent and authorization
References: <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3679399753_1736882192"
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:29:19 -0000

And to those who haven’t been following, there’s already a long list of use cases on our wiki [1]. Thanks to all who contributed!






From: Txauth <> on behalf of Fabien Imbault <>
Date: Tuesday, August 4, 2020 at 15:23
To: Justin Richer <>
Cc: GNAP Mailing List <>
Subject: Re: [Txauth] Decoupling consent and authorization


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 ;-)






On Mon, Aug 3, 2020 at 5:33 PM Justin Richer <> wrote:



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:




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.






Txauth mailing list



-- Txauth mailing list