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

Dick Hardt <> Mon, 20 July 2020 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 319A13A0E0C for <>; Mon, 20 Jul 2020 12:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=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 lXnSS1AjXpAx for <>; Mon, 20 Jul 2020 12:11:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CC493A0E0B for <>; Mon, 20 Jul 2020 12:11:25 -0700 (PDT)
Received: by with SMTP id t9so10327195lfl.5 for <>; Mon, 20 Jul 2020 12:11:25 -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=PCL1dC4fHhx+iqk5oBVtCoBpoRERkQBIx/JTSwgztII=; b=VcCrFLTl9Jwp8RN3cbx8kMGm06ZNPc8y8ShxsGDMhw4CO7sQMyjfdXbNg9gVtOzXpX N4QvQQzkRAczQodBTo0VyItJWzr5l3E1oqChsxZDV9lR+3Sl70DmgsfxDiGiyNC1Lrad AKyz0TLN7iCgNMR4aIniuJd3qinJ+IQCc7QC0wOTm+A4Yk6w9isCXWM6sd9fkw0MfPQm eJxtw+Gp5SMG491ov/sH92L1zoMteLK+k5dRS5k97ZuNYlVAmTRhgrkRB8L8F9ao0W6Q On2lorcqxho0wGq7KrRe5/IVDj2DWFNkGzN+EUQbVoNKfgEbyIRUQl400wmhWse8Dgg8 yxTg==
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=PCL1dC4fHhx+iqk5oBVtCoBpoRERkQBIx/JTSwgztII=; b=P8dWCNEIIWnQPdi7XFWY27S/+u+2dTZR0IGEvVQT7jLFkamzAdsdRGreGKBnPSYipk 8eDjNviU1DDAYxm8m8MY66dw0helF6hCSdQ+E575fXDTE5tAuLwVF3xNalwZgR8/rFg7 saPG0ZJXTX13xZhtstOeVDruOt1sOYLWiaDW0kG8G4hokAvhf2y1Ns0Y1BX99vlEO63n 5Gd3NiCpmf8zxp4nzga9yZjyGUv8jpJPyafaJIzAAk4Ha+TXK+A6em0CKHU40Y8IgGbC jlkksOsiW/+7xLtbIPp8SLru9hUp6Kw0jXdcfz338qpTjwvA1y4PEZShLfPKU4qdquks ySVA==
X-Gm-Message-State: AOAM53092NpDjCHRl5FxTT4KcgIvF3kPeuPmI3+Z2C01Jo9Mh0EePK3i ryys9Y71uC2yXf/eJmrLroJ/GnIbCLwVk80ie9k=
X-Google-Smtp-Source: ABdhPJxgcgsCqOPc+WRo/fvtZ9GsBGi+BNQAted5NYlUt0L6HZxRGjmQtMrAayjU53pDUHdrDjb6npAzPtmc9XKi1rM=
X-Received: by 2002:a19:8044:: with SMTP id b65mr8318323lfd.91.1595272283020; Mon, 20 Jul 2020 12:11:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Mon, 20 Jul 2020 12:10:44 -0700
Message-ID: <>
To: Denis <>
Cc: Francis Pouatcha <>,
Content-Type: multipart/alternative; boundary="000000000000bfe2c605aae44576"
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 19:11:27 -0000

On Mon, Jul 20, 2020 at 2:05 AM Denis <> wrote:

> 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.

When is covered, per the sequence. How and where are out of scope of what I

> 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
> draft-hardt-xauth-protocol-13.
>> 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 ?

If the User is the RO, then the GS knows who to query.

If the RO is a separate entity, then the GS knows the RO from the RS being
queried. An example is a user would like access to an enterprise asset
where a workflow is started to gain approval, and an administrator or
manager provides consent.

>> 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.

See enterprise example above.

> 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.
The user being the RO is the initial use case for OAuth. A client
application would like access to the user's photos at a photo sharing site.
The resource is the user's photos. The user is the owner of that resource.

> Denis
> --
> Txauth mailing list