Re: [Txauth] Registered Clients and Dynamic Clients

Dick Hardt <dick.hardt@gmail.com> Thu, 16 July 2020 17:43 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 276183A0896 for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 10:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 1FsHppQ4BaiN for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 10:43:08 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 1C10A3A0891 for <txauth@ietf.org>; Thu, 16 Jul 2020 10:43:07 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id q7so9057442ljm.1 for <txauth@ietf.org>; Thu, 16 Jul 2020 10:43:07 -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=PFZY4tKPrrvBd8XI/MFW/oeoSloIEh9LBrqVKjgTT1w=; b=n46DRITPmQt6YrX/olwjGv54m+Llv+mi+OAxgQEhFW9xMH2mw++Thvv4Js+Kq/msEi 9NKBQUziqPSuOBB562oa/YfIwS+beih1lDWFMq1wTGh5WJdAXCO8iCHlVQZeYiMv7HZs 6BfVeo65ocfeRgEJm2hHKdzkFFEvcVLwda7B4np7W85xmXc32Yg9iVxMg/Xf41/xZCwI QCorkgeFQheZ2oHZMlopN7FGyF4kzoHspk3icKG3xyh9aJYWYJkoa+j8/PCHDKIlazEN DBINGcd8jcOljKmR5FcpKT1sI0/ZH/EA7KWFcyVlsRnWN4m7UBcWRc0ES847w4YRMPGd VFPA==
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=PFZY4tKPrrvBd8XI/MFW/oeoSloIEh9LBrqVKjgTT1w=; b=c4oC5x2SQT8kupktm31TQU2YO8jAd6RPcsawBXRdGamLo27V9gN1LMMjLGignUE99m yioC2j0U29mdw3xKqR7LrHMwTUZSUx81OSpvvjrFWQwrkXtGAsrx8W9XOBb+MKHRpYKK FYqpCWcyVh671puJ4I226MzQorxj1PNvTtAGyr6y0W3EAOe5n+FymnwsWfrQJ46alQzc KBE75TLxA6k+1aTHnGJB6y3W0cBT5XdvhyILjLIahJbcIp5pEivt52FaxPOg/6GpYCAo FWZfOmRPTTZsSnScRl2XzKA19QMVczZP8v1W9eZQnbFXcZiixbrauRo5Z5xglAJJPdqP c18A==
X-Gm-Message-State: AOAM533z4e22/SAC/xMFB9g7knJW7/ulZqjye5VLU2g6LctF5J/7SJLK BhNo1UKVD5PPr1aQ/1FgvshULhBsetX/3/8fz8SOtvcs
X-Google-Smtp-Source: ABdhPJxSxzptSQTyB7jm/6HbJDxoh7PUf3eCVjtKCX9ibq1KtPFJ9rrufWRYcjGiDwgJstuQHRb3AB333Q6ZXnwrwrc=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr2452561ljp.437.1594921385944; Thu, 16 Jul 2020 10:43:05 -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>
In-Reply-To: <2201d382-c2f3-1496-b368-5b2caeb5eab5@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 16 Jul 2020 10:42:29 -0700
Message-ID: <CAD9ie-tif8Pfj3pOoMVNrUFt5GCRFh12E_mOE22NPEvwuZkcdw@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a76a9705aa92925f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/ZSiLyC1DUT-343j-qW6VaB3RkGk>
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: Thu, 16 Jul 2020 17:43:10 -0000

inline ...

On Thu, Jul 16, 2020 at 5:37 AM Denis <denis.ietf@free.fr> wrote:

> Hi Dick,
>
> On Wed, Jul 15, 2020 at 10:04 AM Denis <denis.ietf@free.fr> wrote:
>
>> Hello Dick,
>>
>> I am puzzled with the two following definitions in
>> draft-hardt-xauth-protocol-13 :
>>
>>       *Registered Client* - a Client that has registered with the GS and
>> has a Client ID to identify itself, and
>>        can prove it possesses a key that is linked to the Client ID.  The
>> GS may have different policies for what
>>        different Registered Clients can request.  A Registered Client
>> MAY be interacting with a User.
>>
>> [Denis]  I interpret the last sentence in the following way: A Registered
>> Client may be either an Application or a User.
>>              Is it correct ?
>>
>
> No. A Registered Client MAY be interacting with a User, or it MAY not. IE,
> a Registered Client may be a service.
>
> It seems that what I call an Application is what you call a service.
> Usually a service may be supported by multiple servers,
> so I get the impression that my terminology is better suited. If not,
> would you be able to explain ?
>

A Client could be an application the User is using, or it could be a
service with no specific User.


>
>
>>       *Dynamic Client* - a Client that has not been previously registered
>> with the GS, and each instance will generate
>>        it’s own asymmetric key pair so it can prove it is the same
>> instance of the Client on subsequent requests. The GS
>>        MAY return a Dynamic Client a Client Handle for the Client to
>> identify itself in subsequent requests. A single-page
>>        application with no active server component is an example of a
>> Dynamic Client. A Dynamic Client MUST be interacting
>>        with a User.
>>
>> [Denis] The draft does not include any other explanation for the reason
>> to support the so-called "Dynamic Clients".
>>             While I can understand the value to use a temporary key pair
>> for a given RS, I can't understand the value for a GS
>>             to support unknown clients. If a GS knows nothing about a
>> so-called "Dynamic Client", then it will not be able to deliver
>>             any user attribute into an access token to such client.
>>
>
> More of an explanation of Dynamic Clients is a good call out, thanks!
>
> A Dynamic Client MUST be interacting with a User, as "trust" of the Client
> is done by the User.
> A Single Page Application (SPA) or a mobile app are examples of clients
> that cannot have a shared secret, but can generate and keep secure
> their own key pair..
>
> As suggested in another thread, GNAP could support Clients that are
> between these two extremes.
> Mike called out automatic registration per OpenID Connect Federation as
> one example. Other options include a "software statement" passed from the
> Client to the GS.
>
> We may want to revisit the terms "Registered Client" and "Dynamic Client"
> as we broaden the mechanisms for Clients to "register" with a GS, but these
> are the common cases today, so I picked them.
>
>
> It seems that the intent is to support both a client registration protocol
> and a client operational protocol with the GS/AS.
>
> Client registration may be done in many ways until the user is able to get
> a *both an identifier* and private key
> usable for an AS, and the AS is able to use *t**he same identifier* and
> the corresponding public key to authenticate the user.
>
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.



> For example, draft-hardt-xauth-protocol-13 states: "The Client always uses
> a private asymmetric key to authenticate to the GS".
>
> This should be the start of the story with an important observation: the
> client always uses *an identifier*, in particular to allow to gracefully
> change that private key.
>
The challenge is that the client needs a unique identifier for the GS,
which is why in both XYZ, and XAuth, the GS generates the identifier for
dynamic clients, and the generally also generates the identifier for
registered clients.


> One way to register and then to authenticate to a GS may simply be to use
> FIDO. FIDO is currently supported by many web browsers.
>

Technically, the web browsers support WebAuthN. While FIDO is great
technology, I would see it as an authentication choice between the GS and
the User, and out of scope of GNAP. A challenge with FIDO is portability
across devices, as a binding is usually tied to a specific device.


>
> If/once we will be finished with the main topic, then why not address
> client registration but there is no strong adherence with our main topic.
> Hence, client registration should not be on the list of our top priorities.
>
> If we define one *or more* client registration schemes, then this should
> better be in a separate and independent RFC.
>
Maybe, maybe not.

My preference is to have a larger document that covers inter-related topics
than a bunch of smaller documents that an implementer has to bounce around
between.

/Dick