Re: [Txauth] Key handle vs client id & handle

Dick Hardt <dick.hardt@gmail.com> Thu, 16 July 2020 20:35 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 06E1D3A0CB4 for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 13:35:06 -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=unavailable 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 oU4CcmMdpr78 for <txauth@ietfa.amsl.com>; Thu, 16 Jul 2020 13:35:03 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 83A9F3A0CB2 for <txauth@ietf.org>; Thu, 16 Jul 2020 13:35:02 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id f5so9787960ljj.10 for <txauth@ietf.org>; Thu, 16 Jul 2020 13:35:02 -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=0WDKieczsshZytlFQw2kPJ8dUvxyCmS5nLoXQsBzNmw=; b=KCOevJQgybXGKL7Qz+Cd1x0RsdoEn/WHIXDk6ybUJwrAPs8UoN3Xq1Uezi9uHx8t62 MeuhxBn/7RYj9ZEirBAdsGXFlakK5BZ5LSEKzaDF41bjTEcym14KA4P4Mf/U2mgW+NWc TwqNfDkIoBsAzLZBDy2qpjfJEWYzrlZM1ckywKcJL1aIX66KpvULj5PMiINed8avfNR2 vZhfTjyplI5sObBEgLOgSpIs7uKNw3p183zZMahbRHsqqYxcQT6t74vyB4jbGsl6lmRB pwaibKaRc6eDoUx7r8+IZ5WeRVXT8F+gr++gyGvUV/fceuxLKKUGcLnQh6bPTr/n2hiS eUNA==
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=0WDKieczsshZytlFQw2kPJ8dUvxyCmS5nLoXQsBzNmw=; b=oyuUfaG+0mfM8FpQeWCRG/VcWJqxTisQA2Yoa/S/VXcqsaaEH1OfUYduJqvc6kaH/U drvYzOxepEE3YzRHGJH3ltLSMtOM7FSv7MN3f2e7TBXN008fXffALF1LMf0kWFAkqbos Ymy4IAf2sV1SzFI9XUUW5FUdUuhj71ad42Pm6mPCNKaG1G1eOkS2uretXqfJnAmq9mU2 IG6RbUuO9HThtz4IJurgWoNkLwo6FR/7yfsvTevRKKXIHahETubKm22mgaJNJZjqxEpZ yoi6qJSJ2D+L6MtvIoZ2ggucPLZDGT1K90CJiAa7oOoLqNfPpJzHmE5yx8Zqm7x/rCKK +TSw==
X-Gm-Message-State: AOAM5324dMCMENWou63l3Q/hLn5ur/U52DAF5dYU1rM4y7WzbK+QhZ4F VZiLD/S9/TMCwtpSXKnHuK82HEVQnpHbSQBkpM8=
X-Google-Smtp-Source: ABdhPJyGYZSgaY+NaTliX7oLxMRFCjRsbjfkmUc/Y4MPSQ50Qg6IGKAgA3R2yxrgpbMwwtNDR4tVcTxu/xzt44rwb4E=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr3024132ljg.69.1594931700425; Thu, 16 Jul 2020 13:35:00 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu> <CAM8feuR=jEoUWY7XHYdBtV1xQL3VBmKYffuS1zTF3hkmNUCr_Q@mail.gmail.com> <BFABF236-006A-4627-9219-3D96AA828610@mit.edu> <CAD9ie-vUn=7rwiMJSJrMdQ=3aeNnhs200eD5dxjgc03OPKdyMw@mail.gmail.com> <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>
In-Reply-To: <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 16 Jul 2020 13:34:23 -0700
Message-ID: <CAD9ie-uzNKRaY8XVwEjVppC_c5q+3c+8vh3jydJGiqUgfF8N=w@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Mike Varley <mike.varley@securekey.com>, "txauth@ietf.org" <txauth@ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000071e8cc05aa94f9c2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/hsHs6qVvMxooUJizhWjIn4Voktc>
Subject: Re: [Txauth] Key handle vs client id & handle
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 20:35:06 -0000

One client identifier was a simplistic example. Org A may have numerous
clients, perhaps in different teams, perhaps in different services, each
with their own policy at Org B.

When one of the Org A clients makes a call to the Org B AS, it needs to
identify itself with some identifier so that Org B knows which policy to
enforce. Why not the Client ID?

I also agree with your comments that other client identification situations
are different, and forcing the same identification model on them does not
make sense, but I fail to see the value throwing out a concept (client_id)
that has worked well for the use cases it was designed for.


ᐧ

On Thu, Jul 16, 2020 at 1:08 PM Justin Richer <jricher@mit.edu> wrote:

> I think that the cross-organizational trust model is an interesting one,
> and in fact it’s one of the things that’s pushed me away from a client_id.
> In the scenario that you describe, “client_id” is used to represent
> something that it was never meant to represent: the organization running
> the software, not the software itself. It isn’t a client_id, and while in
> OAuth 2 the client_id could be co-opted to carry that information, it’s
> considered bad practice to share client_ids between multiple pieces of
> software.
>
> I would argue that to address this use case properly, there should be
> another level of identifier to bridge that trust that the software can
> present, showing that it is a part of Organization A, and not Organization
> C. This isn’t a client identifier, it’s an organization identifier, and it
> should be separate. You might want to identify both the client instance as
> well as the organization it’s a part of, for example. This is part of the
> motivation behind putting “organizational data” within scope for the client
> to send to the AS, after all.
>
> Therefore, I strongly disagree that this scenario “requires” a client_id
> to be solved. In fact, I think that solving this scenario with a client_id
> is an anti-pattern that stems from OAuth 2’s over-reliance on client_id as
> a persistent identifier within the protocol, and we can and should do
> better with GNAP. It’s very similar to Mike Jones’s referenced federation
> document, where the client_id is co-opted as a means of bootstrapping
> client registration and discovery, or in the Solid Authentication
> specification which stuffs a WebID into the client_id field.
>
> With OAuth 2’s ecosystem, we’ve used the tools that we had to solve our
> problems, and come up with some very clever solutions. What I’m trying to
> argue to this community is that we are in a position to create our own,
> better tools.
>
>  — Justin
>
> On Jul 16, 2020, at 2:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Justin,
>
> While I agree that the assumption in OAuth 2 that all Clients have a
> client_id is problematic, the requirement for a client_id in many use cases
> is still there, and it does not represent a piece of software, but a
> relationship between parties.
>
> Organization A writes client software that calls resources managed by the
> AS in Organization B. The client_id represents Organization A to
> Organization B. Organization B does not care what software Organization A
> is running, and there may be numerous pieces of software at Organization A
> that use the same client_id. The access granted by Organization B to
> Organization A needs to be able to be different than the rights granted to
> Organization C.
>
> I agree that we don't want to force all clients to have a client_id, and
> as discussed, there are a variety of inputs for an AS to accept calls from
> a piece of software, and often, that will be a particular *instance* of
> the software, but we also don't want to force clients to all be treated the
> same, because they are not.
>
>
>
>
>
>
> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer <jricher@mit.edu> wrote:
>
>> Exactly — when we start to look at it as managing the lifecycle of a
>> piece of software, instead of a registration at the AS, we can start
>> thinking in different terms what “trusting” the client means in the context
>> of what the client is doing. That trust could come from some kind of signed
>> attestation about the software (like the OAuth 2 DynReg software
>> statement), or it could come from some externally fetchable item (like a
>> Solid WebID, a DID, or the OIDC Federation extension), or it could come
>> from someone sitting at a console and typing in information and getting
>> back an identifier. And none of these need to pretend to be a global
>> “client id” for it to work. The world of clients is much more diverse than
>> OAuth 2 likes to admit, and we see that with trying to nail down a
>> “confidential” vs. “public” vs. “dynamic” vs. “static” vs. “automatic” vs.
>> “ephemeral” vs. … any number of other things.
>>
>> OAuth 2 only needs client IDs because the front channel needs a way to
>> pass client identifiers when the client can’t authenticate itself directly.
>> We tried to get rid of this restriction with PAR and JAR together, but
>> there turned out to be corner cases in OAuth 2’s world that still needed
>> client_id, and implementations assumed it would be there anyway.
>>
>> In GNAP, we can avoid that problem from the beginning by looking at the
>> model differently and understanding where we’re coming from, and why.
>>
>>  — Justin
>>
>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault <fabien.imbault@gmail.com>
>> wrote:
>>
>> +1 on that.
>>
>> We can then see it more as life cycle management of the client than
>> registration per say, and this comes with many benefits compared to the
>> current client_id.
>>
>> Fabien
>>
>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>> I not only agree with Mike Jones that “automatic registration” should be
>>> part of the process, but I would argue that that kind of model should be a
>>> default mode of operation. If you have an identifier that you can send to
>>> short-circuit that, great! But we should focus on having the capability of
>>> inlining a lot of this information wherever possible. This is already the
>>> direction that the input proposals are heading.
>>>
>>> So I kind-of agree that “registration” is in scope for the protocol in
>>> general, and since both XYZ and Xauth have mechanisms that allow the client
>>> to present a key and get back an identifier that it can use in the future
>>> we have something equivalent.
>>>
>>> But I think there’s a little more to it than that: Ultimately, I think
>>> we should question thinking in terms of “registration”, a model which has
>>> hampered the OAuth 2 model in a lot of use cases. For example, the
>>> federation draft Mike Jones references below hacks the “client_id”
>>> parameter and makes it point to a document that the AS has to fetch. This
>>> construct is done for two reasons: (1) Oauth requires a “client_id” in the
>>> request and (2) it’s difficult to pass information by value to the AS due
>>> to front-channel restrictions. Since we’re defining a new protocol, we
>>> don’t need to hack that functionality into a “client ID” or equivalent and
>>> instead we can pass that information directly in the protocol. If we don’t
>>> assume that the client *has* to have a client ID equivalent, but it *can*
>>> have one in a set of defined circumstances, then I think we are in a much
>>> better spot. This is the reasoning for XYZ’s model of having clients
>>> identified by the key, and that key can potentially be passed by a
>>> reference identifier.
>>>
>>> I think all of the use cases that Mike Varley presents below are all
>>> valid directions, with the caveat that we shouldn’t assume a client should
>>> be presenting an ID at all steps. Mechanisms like software statements
>>> should be presentable apart from a client ID, as should on-device keys.
>>> We’re probably going to want extensions for device posture and other forms
>>> of attestation as well.
>>>
>>> This is one of the domains that I think we can clearly surpass OAuth 2’s
>>> flexibility and capabilities if we are willing to look past OAuth 2’s
>>> assumptions of what’s needed inline in the protocol.
>>>
>>>  — Justin
>>>
>>> On Jul 14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com>
>>> wrote:
>>>
>>> Is client registration in scope for the protocol?
>>>
>>> A generic way of handling clients (via ID or Handle or Key or whatever)
>>> is to have processing rule on the AS such as “if the AS recognizes the
>>> client ID (and authentication of that client ID) then it may process the
>>> request on behalf of that client. If the AS does not recognize the client
>>> ID, it must treat this as a new client registration and evaluate any
>>> authorization evidence the client provides before enabling the client and
>>> mapping policies to that client” (this means dynamic or automatic clients
>>> need to provide additional assertions / software statements whatever to
>>> register their ID.
>>>
>>> Something like this allows for very flexible systems:
>>> System A can be unknown to the AS but can dynamically registered each
>>> time with an appropriate software statement
>>> System B can have a fairly stable client ID at the AS, but rotate that
>>> ID every month through automatic registration (with an assertion it got
>>> from the AS during a pre-registration for example)
>>> System C can pre-register with the AS for a client ID because it doesn’t
>>> deal with software statements etc…
>>> …
>>> And even ‘StatelessAS’ can operate by never storing client IDs because
>>> it will always just rely on the software statements.
>>>
>>> I think a client registration protocol that allows these scenarios would
>>> be very useful in GNAP, but hopefully avoiding having to define what
>>> ‘evidence’ the AS needs to accept for each scenario.
>>>
>>> Thanks,
>>>
>>> MV
>>>
>>> *From: *Txauth <txauth-bounces@ietf.org> on behalf of Mike Jones <
>>> Michael.Jones=40microsoft.com@dmarc.ietf.org>
>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>> *To: *Dick Hardt <dick.hardt@gmail.com>om>, "txauth@ietf.org" <
>>> txauth@ietf.org>gt;, Justin Richer <jricher@mit.edu>
>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>
>>> I agree that there are significant differences between statically and
>>> dynamically registered clients and that’s appropriate to be able to
>>> syntactically differentiate between them at runtime.  For one thing, the
>>> resource requirements at the authorization server can be very different.
>>>
>>> We should also be thinking about how to include what the OpenID Connect
>>> Federation spec
>>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>>> “Automatic Registration”.  This lets the client encode a registration
>>> request reference in the client ID, so no static or dynamic registration
>>> even occurs.  See
>>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.9.1
>>> <https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc..section.9.1>
>>> .
>>>
>>>                                                        -- Mike
>>>
>>> *From:* Dick Hardt <dick.hardt@gmail.com>
>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>> *To:* txauth@ietf.org; Justin Richer <jricher@mit.edu>du>; Mike Jones <
>>> Michael.Jones@microsoft.com>
>>> *Subject:* Key handle vs client id & handle
>>>
>>> + Mike as he had interest in this topic
>>>
>>> My understanding is that an existing OAuth 2 client would use their
>>> current client id as their key handle, and a dynamic client (one that was
>>> not pre-registered) would be given a key handle by the AS.
>>>
>>> There are potentially some significant differences between a registered
>>> client, and a dynamic client to an AS.
>>>
>>> The AS is likely to know the identity of a registered client, and have
>>> different policies between the two types of clients. For example, a
>>> registered client may have access to a 'write" scope, while a dynamic
>>> client does not.
>>>
>>> The AS may have 100s or 1000s of registered clients, but a dynamic
>>> client may have 10Ms or 100Ms of instances, which may dictate
>>> separate storage services. Additionally, internal to the AS, which systems
>>> can write to the registered client store is going to be different than the
>>> dynamic client store.
>>>
>>> In XYZ, subsequent calls to the AS, both registered clients and dynamic
>>> clients pass a key handle, so there is no easy way to differentiate between
>>> the two.
>>>
>>> While the AS could embed semantics in the key handle identifier to
>>> indicate which identifiers are pre-registered vs dynamic, there are many
>>> cases where the AS does need to know the difference, so making the
>>> difference a feature of GNAP seems like a better path.
>>>
>>>
>>>
>>> This email and any attachments are for the sole use of the intended
>>> recipients and may be privileged, confidential or otherwise exempt from
>>> disclosure under law. Any distribution, printing or other use by anyone
>>> other than the intended recipient is prohibited. If you are not an intended
>>> recipient, please contact the sender immediately, and permanently delete
>>> this email and its attachments.
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>
>