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

Dick Hardt <> Sun, 12 July 2020 19:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43C093A0869 for <>; Sun, 12 Jul 2020 12:00:15 -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 MUx6Wld951pX for <>; Sun, 12 Jul 2020 12:00:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A365F3A0893 for <>; Sun, 12 Jul 2020 12:00:11 -0700 (PDT)
Received: by with SMTP id c11so6513182lfh.8 for <>; Sun, 12 Jul 2020 12:00:11 -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=6OYPls3zLqQMWI8Ro4BNxfiBQRBYXhDBH0Ne8BXcC90=; b=iK3aSM2ZsCqazJ75WZR6iOrRIVO9lYZNRNX4vn2CbOs80Ya0oSrl59SvN9jrd3rKwj bVpw3zqrVM1m2Wj0Iq+fkWs9zVDuYopkZDnMAoTZLeJzN329dnHrBP0fW9dBGdKVl5Nv BsdmOS0KWUX+7L8HbJEQcTnZUCoqThD0QASIO9fzB9SE50L+gET/OOtrhXEgW9IOCCpo WNUWa+fNr/OhUqrPi4YY20C/dE3xp9RAykAODB1YxgjZQ4tuEUozd/QvipMKkTA3DAC8 gOnWHBXvFDAcw40AnDr7/wTzscApp7ZEHd5YGJNZq6zkkr8Put55qZqrlPCop1FtcQt4 4Z0w==
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=6OYPls3zLqQMWI8Ro4BNxfiBQRBYXhDBH0Ne8BXcC90=; b=YVKgKxEh8qnSAIUQzzawjuy4FfjeeN6n3zODFnZD4hpLkyDtKhp0DxqHJ/oCUTYWmr Yb+cOmUdq2Hkel8Z7DGWVGjeFB7xAk6Da4EZyZVAXswuBePQK2PxW1sggjrctkd4WN47 pNiTKkJUeVisXqZjbXkrBXYE77dz8m4c/YvWdNQqD9LlnOFiSC7+W54NycyxKzvQS+vU YmCppFKlH39HTijauVt6Oy5haJ94LSUVYqoVQtSHVElu4Gf0RFdnETxAiA98UAf8Ye+R Qv9S56JZ7rXKVJCPDAUPbe2hd2/97QP2HGFk597a9sAVUDr22lGpxEWNQ/Uo6KZZTAR4 T1NA==
X-Gm-Message-State: AOAM532xKeKAhMOi21VIE3BRoDeopdge8jtghkYmZpUwd6WFUEWzCvVq dkiIwLAIQEKyo7bKkseZNKS08nsGRUhHVAqLTRnZDjTv2Cc=
X-Google-Smtp-Source: ABdhPJwGmZkhrf9E3n2OdeSoip8TN2pWO1T6wwi38u2V1+Pq6b5S3QU3Bm/L2HSdx8bqJ4onMZ438GvqZMpLtduM0ho=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr23150942ljh.246.1594580074740; Sun, 12 Jul 2020 11:54:34 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Sun, 12 Jul 2020 11:53:58 -0700
Message-ID: <>
To: Francis Pouatcha <>
Content-Type: multipart/alternative; boundary="000000000000ebc19905aa431a60"
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: Sun, 12 Jul 2020 19:00:22 -0000

Francis, thanks for the review ... questions and comments inserted ...

On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha <fpo=> wrote:

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

I'm assuming you are referring to this post:


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

Are terms missing, are the definitions too short, or both?
If you provide specific examples I can work on addressing them!

> 2. Abstract Protocol Flow
> I am missing an abstract protocol flow like the one defined in

That's an interesting point. GNAP also has identity claims, so the abstract
flow is somewhat different (there is no Authorization Grant from the RO),
and not all steps always happen. (there may not be steps (E) and (F) with a
Resource Server)

Would you elaborate on what you think would be useful here, that is not in
the specific flows?

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

Would a reference to #section-2.3
<> in
the RO definition, and more explanation in #section-2-3 on the rationale
address your concern?

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

I agree.

If we do mention that, we should specify how the certificate would be
presented and work. We can do that in the core GNAP document, in an GNAP
extension, or reference another specification. I'm not that familiar with
QSeal. Is it specified somewhere?

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

With mobile apps having URIs bound to specific apps, I think the protocol
would work the same, but I've not worked with SIOPs. Do you have any

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

Did you mean to say '... the picture must also display the "RO"'?

There could be a separate RO in a more complex flow, but we could define
this flow to represent where the User and RO are the same party.

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

I like the word "decoupled" -- would "redirect" then be named "coupled"? Or
renamed "indirect" to "decoupled"?

While "user_code" and "indirect" are both decoupled, the "indirect" has
different security properties as it uses a link, which an attacker can
trick a user into clicking on wherever a link may be used.

I do agree that "user_code" and "indirect" are both a decoupled
interaction, and calling that out would be useful.

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

I have been thinking that the functionality you describe above would be in
the "user" object rather than in the "interaction" object as it is not an
interaction between the GS and the User. IE, the Client presents some
artifact to the GS that establishes the User in the GS context so that a GS
/ User interaction is not needed.

That looks similar to me to what Denis was proposing in

Does that work, or am I missing something?

> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> --
> Txauth mailing list