Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11

Denis <> Mon, 20 July 2020 09:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 964C13A08DC for <>; Mon, 20 Jul 2020 02:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ceC0PGs7zS_K for <>; Mon, 20 Jul 2020 02:04:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D7B03A08DB for <>; Mon, 20 Jul 2020 02:04:56 -0700 (PDT)
Received: from [] ([]) by mwinf5d52 with ME id 5M4t2301L2bcEcA03M4uyj; Mon, 20 Jul 2020 11:04:54 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 20 Jul 2020 11:04:54 +0200
To: Dick Hardt <>
Cc: Francis Pouatcha <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Denis <>
Message-ID: <>
Date: Mon, 20 Jul 2020 11:04:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C76989735FCE20FBC699F4C8"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 09:04:59 -0000

Hi Dick,

> On Fri, Jul 17, 2020 at 9:21 AM Denis < 
> <>> wrote:
>     Hello Francis and Dick,
>     The good news first: we are making some progress. We are now close
>     to an agreement with steps (1) up to (3),
>     ... except that the place where the user consent is captured is
>     not mentioned/indicated.

This major question which is currently left unanswered is where, when 
and how the user consent is captured.

Another important point to consider and to explain is related to the 
assurances that the user can obtain about
the respect of his choices. This point is currently left unanswered in 

>     If a RO needs to be involved and since a RO is directly associated
>     with a RS, why can't it be directly queried
>     by the appropriate RS after step (2) or later on ?
> Good question. Perhaps you can expand on a use case where that would 
> be useful?

Before I expand, would you be able to explain first under which 
circumstances a RO needs to be queried by a GS ?
How can the GS identify which RO to query ?

>     Which information is supposed to be presented to the RO ?
>     Which information is supposed to be returned by the RO ?
> Just like how the user authenticates to an AS, how the AS and RO 
> communicate is out of scope.

At the moment, the usefulness of a dialogue between a GS and a RO has 
not been explained, nor demonstrated.
The question is about the functionality of that dialogue in terms of 
input and output information (and not about
the design of a protocol or of a user interface). Anyway, AFAIU a 
dialogue between a GS and a RO is optional.

> For many use cases, the User is the RO, and the interaction is through 
> a user interface, not a machine protocol.

Wait a second. You wrote "the User is the RO". The User is attempting to 
make an access to a RS by using a Client.
_That_ User is not the RO of the RS.