Re: [Txauth] Registered Clients and Dynamic Clients

Dick Hardt <dick.hardt@gmail.com> Fri, 17 July 2020 18:07 UTC

Return-Path: <dick.hardt@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 DBF763A0A11 for <txauth@ietfa.amsl.com>; Fri, 17 Jul 2020 11:07:38 -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 ralyZWxDJtGg for <txauth@ietfa.amsl.com>; Fri, 17 Jul 2020 11:07:37 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 2D2AC3A0A09 for <txauth@ietf.org>; Fri, 17 Jul 2020 11:07:37 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id u12so6549721lff.2 for <txauth@ietf.org>; Fri, 17 Jul 2020 11:07:36 -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=uwhG1CJJlBF/AkqajzxOqyTunpEsp5sWpw3kRQ65wdA=; b=tlZK6FTOf6PTugDUDsPwT23vnSRCW0LYg3NPEvMo4iP26bI496dAiafKQIW/LuGqn7 zD32V+Z0lW4ZtWwn2svFRR20WYPwk3ib9czKD9YdE7x6Q9dWj39EUf253tIcGnZrYVgH 5EQkUxKrMrHOU2STH5TSUXQGh+MtpGDFrQ2WbOD5/TTB93vXD8TWafGIi95PT7vK4jsX QLJv6JdLxgxNh81tcBwp7FiTQlshggtAeljIeBTcQ5+Ti7fABQFo7gUrS/hUC+r1MNap +O8GC2aGcg4VQ75oENoBqGs72SBa5E6iUOOY0YHlrRx5Sz/X2ar837TbcfVocP3gSZTH y07g==
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=uwhG1CJJlBF/AkqajzxOqyTunpEsp5sWpw3kRQ65wdA=; b=DntMNb8uuepJtGZvtU8RYiw1qNo4SfU6RFb3xe7EPU/T8yRNRE1FBCczRSBroL/c32 9gWjH62Y98Xh6t4oe4TsFfqPAwROxVMDfgZu8ulShH8kSW+/M8NTYaZEsASGPR44IcEw K6k94ifDQ3RSYNiZmc/IUxiaxvZN4UccS5YB7q+zMycA9q2w1z6JqRXCdwciBB7Uls8r H2o+nwK+M1q5Zn1mi/XjTKaCux3ebDm/YBFiTAvcgvSMqM0ejB4xnoUqIapMp/dEDWeC 1l5CyVZlBYc2casrAqQDy0IdW+m7JZ//Gw2I4wvIQjxQNmKRSNl59f7YnrzMIUzdof1I smxw==
X-Gm-Message-State: AOAM530qUN72raLNXL5GkIIIsF4Ofjik4WDuaCeZs7+ttYmXfkXhXC0C wm5bHKKJsjQPLQA++DAVbILwClrU5gP+eb79eyU=
X-Google-Smtp-Source: ABdhPJxqyvkyyUsdN3dHM5wWX/sQMME53p5sLzyjaGBJJxQavl8dQYdPlANylYxEvvLLFC6bz0r+4X8Op4jl/q6mQqs=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr5218198lfm.23.1595009255044; Fri, 17 Jul 2020 11:07:35 -0700 (PDT)
MIME-Version: 1.0
References: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr> <CAD9ie-v5cXxbJrRi7V1v52F5SpUkdbaZZ7Twb0DYREK1CMku3Q@mail.gmail.com> <2201d382-c2f3-1496-b368-5b2caeb5eab5@free.fr> <CAD9ie-tif8Pfj3pOoMVNrUFt5GCRFh12E_mOE22NPEvwuZkcdw@mail.gmail.com> <87fe40e8-7e00-3684-ce12-3ec28fd69c28@free.fr>
In-Reply-To: <87fe40e8-7e00-3684-ce12-3ec28fd69c28@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 17 Jul 2020 11:06:58 -0700
Message-ID: <CAD9ie-sf1K9-TmhixP5p_AevpVvs4DgX+H-6ZXHWXxu4p3G57w@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000f7c2e05aaa70812"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/KJX2W2dR-q-klFCDpX4S5E6bj9A>
Subject: Re: [Txauth] Registered Clients and Dynamic Clients
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: Fri, 17 Jul 2020 18:07:39 -0000

Comments inline ...

On Fri, Jul 17, 2020 at 9:09 AM Denis <denis.ietf@free.fr> wrote:

> Hi Dick,
>
> I picked three of your sentences below :
>
> It appears you are mixing client identifiers and user identifiers, as well
> as user authentication at a AS, and client authentication at an AS.
> User authentication at the AS is out of scope of GNAP as I understand it
> (there are lots of existing mechanisms that work fine).
> Client authentication to the AS is in scope.
>
> An AS needs to authenticate users in order to relate them to their
> attributes: there is a user account at the AS for each registered user.
> So user authentication is one important step in the protocol. It shall be
> handled using an asymmetric key pair.
>

I think user authentication is an important step, but I strongly view it is
out of scope of the protocol. There continues to be innovatio in user
authentication, and there I fail to see the value in GNAP standardizing
what an AS MUST do.


>
> A client is a piece of software and/or hardware trusted either by an
> application or by a user that interfaces on their behalf with ASs and RSs.
>

Given that a client is making API calls, I don't see how a client can be
hardware.


>
> An AS usually does not handle clients accounts. It may be interesting in
> some cases to make sure, from an AS point of view, that a user is indeed
> using a secure element with some specific properties. But at this time the
> wording "secure element" has not been pronounced. If we would like
> to go in that direction we would need to describe APDUs (Application
> Protocol Data Units) but at this time I am not aware that the IETF has
> already
> addressed such topic.
>
> However, I got the impression that the real need is not "entity
> authentication" for the client.
> Would you explain the rational for your need, instead of the solution ?
>

A reminder that there are many other use cases for GNAP than your use case,
and that supporting existing OAuth and OpenID Connect use cases is in
scope. Often, what an AS will grant a client is dependent on which client
it is, hence the requirement for "entity authentication".


>
> I picked another sentence:
>
> A challenge with FIDO is portability across devices, as a binding is
> usually tied to a specific device.
>
> This is currently true with what the FIDO Alliance has currently
> published, but this can be solved.
>

Maybe, but it is out of scope of GNAP, and I don't think we should design a
protocol based on what we would like another standards body to do.

/Dick
ᐧ