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

Tom Jones <thomasclinganjones@gmail.com> Sun, 12 July 2020 20:47 UTC

Return-Path: <thomasclinganjones@gmail.com>
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 E57733A07F2 for <txauth@ietfa.amsl.com>; Sun, 12 Jul 2020 13:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GE_OeKyYm9Mm for <txauth@ietfa.amsl.com>; Sun, 12 Jul 2020 13:47:51 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 8024B3A07F4 for <txauth@ietf.org>; Sun, 12 Jul 2020 13:47:51 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id c25so8079191otf.7 for <txauth@ietf.org>; Sun, 12 Jul 2020 13:47:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UgfvlZMRIhU5eGRS5iaFHedsTuJFwxipiGwQrq262zA=; b=QwEZU+ZMHY6aDD6HfKUs4DgkeTqi/yAu5xgDcsEd0jwK6w85p1x8sKk419x/yMyqli CsPLhZT0uluOJDM3ocZ81c398D7iNu8H/mV9M2W2HrBdVzXfW6IKKZ9jVLq3AqBPaT2A 4inAyFv0ezasHJBNoYwAOKE66G1DIiYSRGY3htJHTd94hTPzCmSz4sJ0ELzCRDkG4BRd heWlLGWv69NJkgPc/gkeDb0pgs9lpdA1FUF1JVZXHNatOaXJSLcA9lnH0niFlWlqgnkZ u9EubtF++hNSAqCxdEU2L48G1c/H5ZvJNjam5mlYKU2ZXEaG5NWGm/D1whXI+3Nb03dY hRmA==
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=UgfvlZMRIhU5eGRS5iaFHedsTuJFwxipiGwQrq262zA=; b=jgzpr5j4qwXhr2EHhrNtpce9QOCG0+iRKtAkuQyz54WNzpZlcRXbacxqtihBVJEyut GyNL/8oW98VTN/ncdl9Kp21mSoXkuze3qun6HHK7FbwFFcj3crSZvUFOrOufG8ukW3qf wLu/TyrvCscMi3AHZGkFD8kNkMbqTp2DcclMCc7cLETnpSqkFC4ADuiNo2hmry24EWfJ a12FVsT2l/2Y5Vh5g5zRmqMb1gDMw2igrOplv2uFZhh9uZevP0DkY43WtzcpCgdP6X0M KGRixVekNP17P94JnkeNq872JKiJetOO8DO+hp0MhdW7S/VTlpY6pkCp8HFb5fv8+v+E NHgQ==
X-Gm-Message-State: AOAM531ZrXenJ1Ycm0RQcTVs5Aq9RUNUU8aOoUX4aj/h5gnh5yGKoRkc d3c8YJL6G/hJSDkbVB71QYeuoCS5HAxT7ci/N/Y=
X-Google-Smtp-Source: ABdhPJxtVnILqnrcg8ckq9pw/sFvW9bPTeU61gAFARRy0lfvZnRoLH/eO3BT+ApRFhV9YU1lLe3BU3TBF0y6Qu56f1I=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr49305613otm.358.1594586870549; Sun, 12 Jul 2020 13:47:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com> <CAD9ie-vV4oh9Qk3Y0sPeewo4jby_S6a=HKTZnoqByxJ6tCHJ+Q@mail.gmail.com>
In-Reply-To: <CAD9ie-vV4oh9Qk3Y0sPeewo4jby_S6a=HKTZnoqByxJ6tCHJ+Q@mail.gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Sun, 12 Jul 2020 13:47:38 -0700
Message-ID: <CAK2Cwb4+LNLLL6Hj33FRXT1RoGW1Pdv5oPjPcyp-tV5dgRESjQ@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>, txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fb911c05aa44af09"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/8BPJd1pxB1Y0m_cnl5m1VSKXMYU>
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: Sun, 12 Jul 2020 20:47:54 -0000

Our health care solution is aligned quite well with Francis' design.  WRT
the client to GS assertion i recommend the use of the entity statement from
the OpenID federation spec.

The major issue with SIOP is getting some assertion that the user
device/app is trustworthy.  Kantara is working that problem right now. The
issue there is creation of some sort of "software statement" that could be
attested.

Peace ..tom


On Sun, Jul 12, 2020 at 12:01 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> Francis, thanks for the review ... questions and comments inserted ...
>
> On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha <fpo=
> 40adorsys.de@dmarc.ietf.org> 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:
>
> https://mailarchive.ietf.org/arch/msg/txauth/v-iH5ID8VaOojx7fGniffrxCQdo/
>
> Correct?
>
>
>> 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
>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>
>
> 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 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.
>>
>
> Would a reference to #section-2.3
> <https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#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
> concerns?
>
>
>>
>>
>> 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
>
> https://mailarchive.ietf.org/arch/msg/txauth/kgTKFHZDRDsXJlwW95Gqv_-LctA/
>
> Does that work, or am I missing something?
>
>
>
>
>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead
>> adorsys GmbH & Co. KG
>> https://adorsys-platform.de/solutions/
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> ᐧ
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>