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

Francis Pouatcha <fpo@adorsys.de> Sat, 11 July 2020 17:04 UTC

Return-Path: <fpo@adorsys.de>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C19BE3A1106 for <txauth@ietfa.amsl.com>; Sat, 11 Jul 2020 10:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BGoR74EwS4gY for <txauth@ietfa.amsl.com>; Sat, 11 Jul 2020 10:04:56 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 516453A0F06 for <txauth@ietf.org>; Sat, 11 Jul 2020 10:04:56 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id q5so8992639wru.6 for <txauth@ietf.org>; Sat, 11 Jul 2020 10:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:from:date:message-id:subject:to; bh=frcmXX+jeJ+m82OIVFYggTDUCmans7XNvzAkeBup0Vc=; b=W8AZDlDVC8gmC0ooOqA0VkZpfOkO/CecryldhQ1fS1bcW+oXXxmohWDk0aiX2aG+0p Tg101bQkZqUxR/hC9rXqm2J6BYRZB8bo5w1hUFrakVGRAAlZF9dXTIDZuhfWtU9k2w3N xgE0lTxvKN8CkLFZGiFNhyurMUbIT7Pmxsac0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=frcmXX+jeJ+m82OIVFYggTDUCmans7XNvzAkeBup0Vc=; b=VABbB+xg9lJx7q1b/XeFT2ZZXgN9jO4y+T44NviH6eurglCzsNmqiR8ye7JJnTH5M1 v5TSRH7DOVZ/lcnsyjHdP08ag5sArvCCIQQgYjU/ZNzM4wkenH4OT8VfowxT3pRoJ8Py oUspNwdeFfF+/LVva0xN6vpGAnj28VofsJLFYB4n1KV/KjrVuhpAjpfuYX7lZPLtZoIe 1xrzfOb2jH3KCi92tHSQp2tfx1LFDiaW/9nlPxqhT+KIfL0tQgdQp5xB4d90xBNZ6dZz N5GCbUfrCxoCtqNBuSzrwaH0y4FdcBOxUOOqNb9TcI3FtrG3yiaCO8vs1lN6BarfDtFU awcw==
X-Gm-Message-State: AOAM532C3FluQqqOmUjEeC4uA9RxVjR5N8jwZ7/ZANmy5jfksYGLDgMn Dyl87RjAttfXDj+9DJUo5s0oxNw62ktbBO1EVFIQUVkRhmE=
X-Google-Smtp-Source: ABdhPJzmB9AVZw2Qn77pds6RiAJG4P3A5e0WUwgT2Dp9mriugTh1NC70rTmuVoQq15GXIA6qHiKN6zePqODLk0BJCnQ=
X-Received: by 2002:adf:fd8b:: with SMTP id d11mr79609952wrr.371.1594487093094; Sat, 11 Jul 2020 10:04:53 -0700 (PDT)
MIME-Version: 1.0
From: Francis Pouatcha <fpo@adorsys.de>
Date: Sat, 11 Jul 2020 13:04:42 -0400
Message-ID: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com>
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c8828d05aa2d741b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/o0uh2QHpNAYPM4fGKmBLaWt-IE0>
Subject: [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: Sat, 11 Jul 2020 17:04:59 -0000

Some points raised here might match what I wrote before after reviewing the
last draft of XYZ.

1. Dictionary
I do like sections 1.x dealing with terms but this is kept too short. I
have noticed that most of the discussion conducted on the list results from
different understanding of terms used.

2. Abstract Protocol Flow

I am missing an abstract protocol flow like the one defined in

3. Parties
a) graphical illustration (#section-1.1)
I do like the graphical illustration in #section-1.1. The main difference
to the picture in https://tools.ietf.org/html/rfc6749#section-1.2 is the
clear separation between the "User" and the "Resource Owner" (RO). To help
transition the understanding of current oAuth2 implementers, it is
essential to illustrate and highlight the rationale behind this design.

b) Dynamic Client (#section-1.1)
I would like to mention that the dynamic client can present a certificate
issued by some authorities known to the GS. This is the case of QSeal
certificates designed by European eiDas.

c) Grant Server (GS)
If the GS is a SIOP running on the user device, how does it influence the
protocol design?

4. Interaction Modes (Protocol Flows)
And mentioned in my review of the XYZ protocol, I am missing a grouping of
interaction models. We need an abstraction layer in which we define groups
of flows based on key interaction between parties. I am expecting at least:

- "redirect" Interaction
here the GS instructs the Client to redirect the RO/User to the given
URL. This is well covered in #section-2.1. But for transparency this
picture must also display the "User". Shall the redirect interaction
presume that the "User" and the "Ro" are represented by the same party,
then it is worth mentioning this. In this case we can draw a single box to
represent both.

- "decoupled" Interaction
This interaction model is currently represented by the "user_code"
Interaction (#section-2.2) and the "indirect" Interaction (#section-2.3 and
#section-5.2). Both of these are forms of "decoupled" Interactions. Main
characteristic of a decoupled interaction shall be that the device used by
the RO to interact with the GS shall be separated from the. device used by
the "User" to interact with the "Client".

- "embedded" Interaction
With the evolving of smart end user devices that can keep private keys,
perform cryptographic operations, it is essential to include the "embedded"
Interaction in which RO/User device send authorization grant to "Client"
that in turns takes it to the GS in exchange of the authorization token. In
XYZ I found this hidden behind the didcom interaction.
The "embedded" interaction shall open room for different types of
synchronous transaction authorization requests in which the "RO/User" gives
a verifiable assertion (inkl. proof of possession) to the "Client" for use
at the GS in exchange for the seeked access token.

Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG