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

Dick Hardt <> Thu, 16 July 2020 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96D343A09C6 for <>; Thu, 16 Jul 2020 11:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lAIUADg6GSqh for <>; Thu, 16 Jul 2020 11:00:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F6693A09CE for <>; Thu, 16 Jul 2020 11:00:55 -0700 (PDT)
Received: by with SMTP id e8so9225404ljb.0 for <>; Thu, 16 Jul 2020 11:00:55 -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=jCZKVkoMVcJYzFIOTFoOlAEFhJMObgkZ8DGI9+xo3EA=; b=RCZ90qSbOt1y/EwOmRpMOGO0Bb2Y9AWlw8hTsZ7KjTTBTWG/2zvIL6loe14EUhHecU 8DtibIRAZ3ct+bLjZJVtUgJGh6Wr54gjX68Cqu+Bf/RA891bUSCzCB694TE6jU4rbxCt haNM1ma68/ioEeBcP17l5iy0JpkwfSLy8K1FCb2fkDNpVfOG/B6vGOReftaEP5bZhs4s ppKPRU0OpiMmW1V2lug1aZuoIq/vwT8pY/M5CRV+iFPR51RTrlBNIjqb/NYQks1a1/oa Im2onRbQyWM0rfdLMsxmeZARKGBjrm9uh23JmD2F4AVtWjif5RV/be1sL9IEO5efVSQg qr/Q==
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=jCZKVkoMVcJYzFIOTFoOlAEFhJMObgkZ8DGI9+xo3EA=; b=pxL4mx+AUSLeeupPBML0/XKk4ISPYfxGCBbgG95jsr198fQfcTX+D94UFKSV4g6rEc X0gPvHp7cZqXicDT4PiV35QrTX0u0w1lYUdBo9N0we5W1zIC139U3DrRsn59mp++WG4E HhMzuQypmN7hKNXSegSXw/9MKoY8qLpKR1oF5Mwx9+p1zNH24tlRR6XJ0h58XK+dunBK HH2PWj6oDQhAeYjkgq9SwwGwJiv8deOSL+atXu9x/77M3Rts5wwocNcJB8LG6Ugh7eEp ooIHJOZ6eUvZVEdlPIJAuZ/jUOaWtffDlvOJvcEsTiZEp+K1T5aZZRs7tY2tSbsgvQd5 K86w==
X-Gm-Message-State: AOAM533BEGfIkmacrcTVsyC61oZByfkxDI1NOA8O9KONJIJpPSdVPZjN ET3iZbD5MNajo7uSk+/YN6qZ3JGtiF8ZCCQtgws=
X-Google-Smtp-Source: ABdhPJwEXPK76MYQn0LnwNTWF8OCzzDiEnsdXux4dX+LTMi2C0GQRnoSwu9sHGrpHmP3i/QCnjk9SrNxOP7Ij99H6Q0=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr2762367ljn.5.1594922453237; Thu, 16 Jul 2020 11:00:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Thu, 16 Jul 2020 11:00:17 -0700
Message-ID: <>
To: Justin Richer <>
Cc: Fabien Imbault <>, Mike Varley <>, "" <>, Mike Jones <>
Content-Type: multipart/alternative; boundary="00000000000045043b05aa92d247"
Archived-At: <>
Subject: Re: [Txauth] Key handle vs client id & handle
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jul 2020 18:00:59 -0000


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 <> 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 <>
> 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 <> 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 <>
>> 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 <> on behalf of Mike Jones <
>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>> *To: *Dick Hardt <>om>, "" <
>>>gt;, Justin Richer <>
>> *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
>> 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
>> <>
>> .
>>                                                        -- Mike
>> *From:* Dick Hardt <>
>> *Sent:* Friday, July 10, 2020 1:17 PM
>> *To:*; Justin Richer <>du>; Mike Jones <
>> *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