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

Tom Jones <> Mon, 20 July 2020 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 677903A0D77 for <>; Mon, 20 Jul 2020 10:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_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 HbovL4qg0iKc for <>; Mon, 20 Jul 2020 10:27:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FFFA3A0D76 for <>; Mon, 20 Jul 2020 10:27:28 -0700 (PDT)
Received: by with SMTP id 5so12783778oty.11 for <>; Mon, 20 Jul 2020 10:27: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=p1woeKbBI8SNoM3Uj51JJrkv9Z+rJ7LTvQ+LL/9jNvY=; b=dYkA9ml2umN0nm64wQe/6w5iyqUl9yDJvjvCZpPw+CmosAZ3lC/cG9ExL7uUn5FdOw 1p560o2Nw7gcIhdC65xscLAkX+ldt2w9BRK6mbU4/lrwL5Vc3HZyMpA/RQSC3T+89Y4O L3b7uTgR3WPGVDz/vfj2rkM3QcVCCuZ1ym3ArIpPk/0Gv5OwzfiOFs6sxo03KjzaIdMI xQpeZ8RunbxRBEdDRZtsm/M11rrjGl8eAVgZAhORtgGmOtLv4lypA6m365Ry5GqEmtaR Pe0VmtnSWKkjK2DnC5GPUfrTMuA3WU0swB1P5YkhRxCOa9pc6S+ipLUCxTtSOXCQndlL 1Hqw==
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=p1woeKbBI8SNoM3Uj51JJrkv9Z+rJ7LTvQ+LL/9jNvY=; b=RvZ66R4IziutYaeevD1HfGMv9ScAQRDqg8hEKL2SfDRMpBDpBAoE84F1WwCVOMgJoq 8Y5Q6UbAtwmagKhJfguHl5uTW6QGRZWT1WJlU/MkgJ5YXU4DDJtg2F+lT8MrxAN6wB8I 0tFUoRJcZbrXTPI50B/NHIuouTf/9/K/u0PQQWffQdPJeBsj1MjdpZaKKpX/GlDQAyna 0iDejzfv9/1DEvKIL332SXKGsVlWw7DngLrYsyO2P26tUdjSbtbU64OOOK+ogT14Oq5U vwLoI2YmQb2ikWHNe/Sa/KYW7v069ByyIcw+bPtf8kKd4GegCUOIyqFDzWlZuVhMRU9w NBTA==
X-Gm-Message-State: AOAM5314PCyQxZQWiscP5bP/W26KrZAxbFTT9p5NxIncl2vTOPT21EKr Qpwxfo6TyXBXvQdpCi8FrkRvIB4ihynhmT5eTzs=
X-Google-Smtp-Source: ABdhPJy87m7v9HoXWk+owbISCkCNdwipxgcVNGsnLI/S8iIwYcntO/hlTja4hTupLbE2LzKJg7uOqzLDVHBYSA4E66M=
X-Received: by 2002:a9d:a03:: with SMTP id 3mr5588322otg.87.1595266047585; Mon, 20 Jul 2020 10:27:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Jones <>
Date: Mon, 20 Jul 2020 10:27:16 -0700
Message-ID: <>
To: Denis <>
Cc: Francis Pouatcha <>,, Dick Hardt <>
Content-Type: multipart/alternative; boundary="00000000000016b2e005aae2d216"
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 17:27:30 -0000

This interchange exhibits an essential problem of most of this work. The
idea that humans populate the web. I have yet to see a human with an
ethernet connection. So i must assume that the user agent is the essence of
the human on the web.

Second there are two terms which need to be distinct in the general case -
at least where the RO is a human and the resource contains PII.
The RO aka subject is the identifier that is used by a real world human
that has data on the web that is (inter alia) PII about them.
The user aka guardian (and often also the subject) is the identifier that
is used by a real world human that has acquired control of access to the
PII about the subject.

Peace ..tom

On Mon, Jul 20, 2020 at 10:13 AM Denis <> wrote:

> Hello  Francis,
> Hello Denis,
> On Mon, Jul 20, 2020 at 5:04 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.
>> 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.
> [Denis] These two major points are still left unanswered at this time.
>>> 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 ?
> In all circumstances. Can you name a situation where this is not the case?
> [Denis] This is quite easy. The final decision is always taken by the RS.
> If a Client presents access tokens issued by ASs trusted by the RS
> that contain appropriate attributes to perform the requested operation,
> then the operation is allowed.
> If really a human RO needs to be involved for whatever reason, it is
> possible to get its involvement when the Client connects to the RS.
> However such involvement does not need to be formalized by a protocol. It
> can be application specific.
> How can the GS identify which RO to query ?
> There is supposed to be a preexisting relationship between GS and RO, If
> not RO will have to register with GS in the first interaction (onboarding).
> How can the GS identify how to connect with RO?
> GS must evaluate the RS provided info in step (3)
> AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is where
> selection of interaction mode takes place.
> [Denis] This means that a GS must have prior relationships with the RSs
> and ROs. While this should not be prevented for backward compatibility with
> OAuth 2.0,
> this should not be the single case. Prior relationships between ROs and
> GSs is a door half-opened for Big Brother. If in addition the GS is able to
> know which operation
> is attempted by the client on which RSs, then it is a door wide-opened for
> Big Brother.
>>> 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.
>> The User interacts with the Client.
> The RO interacts with the GS.
> In some use cases (where we use redirect interaction) we assume the person
> controlling the "User-Agent" is also the person
> controlling the "RO-Agent" and they reside on the same device. These are
> cases where we say User equals RO.
> [Denis] Sorry, I have difficulties to understand such a case. A person
> giving his consent to himself ?
> Denis
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> --
> Txauth mailing list