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

Francis Pouatcha <fpo@adorsys.de> Mon, 20 July 2020 15:27 UTC

Return-Path: <fpo@adorsys.de>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BCA3A0C4A for <txauth@ietfa.amsl.com>; Mon, 20 Jul 2020 08:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX1i5I3OE4fi for <txauth@ietfa.amsl.com>; Mon, 20 Jul 2020 08:27:25 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5703A0C60 for <txauth@ietf.org>; Mon, 20 Jul 2020 08:27:24 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id a6so249687wmm.0 for <txauth@ietf.org>; Mon, 20 Jul 2020 08:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JWD3ECpeNGFrz69bGmpucA0TBqlm9CLHjl7lPe34Kwg=; b=PSATJM5Gq8ttW+98xUpQtGtOR8DrBFmx18VexUwC2Ho41M74YD2NHdRhQEP38IlkJY UcDS8YCTLNJO4dXx/gX1J6PA6qzeaVSxHJlG9BwlEg1jpf0vGwj+1a5HOupCVcVSAkKx pnu5CQLbR0qd4Fpz9Uy9R9umjK9jx8Y238uoU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JWD3ECpeNGFrz69bGmpucA0TBqlm9CLHjl7lPe34Kwg=; b=YuvzNPV6Knb2KbLPd57hE86FFGfqBiy9ZKlEtDAlKjjAkXS8jZR5z310pBh1Wf2NqT XRhqYtUxBcPCuk2rA/Ih3xs/G3TbcSkwQN6F68E8v1IYthXMNJsNqmC2VX94DOFJN+6P e6mVlmmBMYGWFiOt3p1Vh9RDJv8upsyQ/N2Sb4RE2KBWK7G/h8q+O+ZurlGYC2guFcdu IsNrt0cLsG5svHtuiKhGFFd7ZNXUKh73Ay2MX5Q2z2fDwK5msihato0wVYulQ0v4p3zP j2BuA58O2Op/I5Z3X02oPfMEMfJc1OilGiLCX2Uj2GUWMUzUS3Q0s4+WToYPNmMKj4oo zNDg==
X-Gm-Message-State: AOAM532nVkjTjQVkYzgEysJMOCarB0rZO3KtFeNS/laSsRSacaMof3Gf 2dFuvGNfGOvPgZobNYWiI24PiVgAYwjY7Es5Fh6WZIfeCZc=
X-Google-Smtp-Source: ABdhPJy0DXZnbHBBPvHIv4uTLFJ1sAe1bSXguevqUJm8tBxvDDiyLpGFeUhWO5bbu7oQFYJSZs5csE9ELrPY7nxEe/U=
X-Received: by 2002:a1c:6289:: with SMTP id w131mr20934186wmb.64.1595258843207; Mon, 20 Jul 2020 08:27:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com> <CAD9ie-vV4oh9Qk3Y0sPeewo4jby_S6a=HKTZnoqByxJ6tCHJ+Q@mail.gmail.com> <CAOW4vyOQYvHBBPjMSNx9=S66_JY4RVcVi2DiqL8OjXUyvzxg=w@mail.gmail.com> <CAD9ie-tou5mTnWVguNygj-D6xUdTRjqvxi-+jhC6NbDFY8ZVJQ@mail.gmail.com> <CAOW4vyM0LycEf8q1T4jF=1g8aFyeLw1b4z9emNKWOG=+4iGgzw@mail.gmail.com> <CAM8feuSWeianPu=BD0WVTv5oB+U4ZkjhtKjnAG9RFk15VqJqWA@mail.gmail.com> <CAOW4vyNTXso=tusCrzDVgM63xH4hDsx6epO6tAhh1YekbWBA0A@mail.gmail.com> <f00c75a5-f930-81a6-a50e-2eeffedac691@free.fr> <CAOW4vyOHO1We4UpCPJBKYvj22rsFd1EN6fAXw8w6YOYTUDhF=g@mail.gmail.com> <aa1381a2-5b11-f7c7-a547-cddb36732c0b@free.fr> <CAD9ie-t7ZFrODeXy=Xzvsv-6gvUY=KjW0ETf8vJYkW2p=G4boQ@mail.gmail.com> <CAOW4vyN26rnOFb+vsaxgaMzeBOsyeSUBougvjHuhQkHyYhnn2w@mail.gmail.com> <b8a83294-771f-c1d7-0956-d0a50accbbb3@free.fr> <CAD9ie-soUmghr-qxWFRhHkX3rx3qaf3wBqxkwRZ=ZfQaSoDwbw@mail.gmail.com> <df110f7d-7928-4dd2-9c09-4b169860623a@free.fr>
In-Reply-To: <df110f7d-7928-4dd2-9c09-4b169860623a@free.fr>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Mon, 20 Jul 2020 11:27:12 -0400
Message-ID: <CAOW4vyMx21H4pBdhAkwoUAJzntFNzjT8hn=Fq=XZKVYLLdgiAA@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Dick Hardt <dick.hardt@gmail.com>, txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000acaf1205aae124bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/lF9V3iyA6YYVIfkdXnglBTAig-E>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2020 15:27:31 -0000

Hello Denis,

On Mon, Jul 20, 2020 at 5:04 AM Denis <denis.ietf@free.fr> wrote:

> Hi Dick,
>
> On Fri, Jul 17, 2020 at 9:21 AM Denis <denis.ietf@free.fr> 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.
>
>
>> 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?

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

>
>
>> 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.
-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/