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

Francis Pouatcha <fpo@adorsys.de> Mon, 27 July 2020 01:56 UTC

Return-Path: <fpo@adorsys.de>
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 A86BF3A15DC for <txauth@ietfa.amsl.com>; Sun, 26 Jul 2020 18:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, 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 (1024-bit key) header.d=adorsys.de
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 n68qLqY_wPI8 for <txauth@ietfa.amsl.com>; Sun, 26 Jul 2020 18:55:57 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 32B693A07C5 for <txauth@ietf.org>; Sun, 26 Jul 2020 18:55:57 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id x5so12096190wmi.2 for <txauth@ietf.org>; Sun, 26 Jul 2020 18:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pSs60gbpD7sN7TVin2M9VXOMc0yXAwO0ugGajuQS9v0=; b=ABbKoCRG+V+/Z8my/PqhBc7NeP4Yl94p/YPoiyNLH+UuHSf9mhO+exLofxECaySAcP ZHE/h0zBuzxnTiS4savrsNa99zDDXd/BK//9zQ96PbLNQnrpDbp3UXFRN5K2qm6ANQL2 NnB+lEIqr5IqvdwP/8qnz4gFizY9rRbakeZyg=
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=pSs60gbpD7sN7TVin2M9VXOMc0yXAwO0ugGajuQS9v0=; b=nZtLanBw+/R/TlqPHLpKqscZxKsDwgrMeoKctUVdRg4igAgsJ35UwzzqmzmfltZumo IriX2XQcZzUEreDPlnh7s0pbniOFxVRuopzeo2Ln1P8eawevy7SbrL3wjK2q1z+VWsul f5CxEUedXTuaHgXkktRZJt0pPV4Bm3j0CSTzzYePpFIskgnzDOOUIEk094zjSYmqmlrs +EvxOb9MH/13N25wZHLL5T7eHUuv/PrreWG+JjL8Q8NG21cvA3dTfXKfcRYy0tVXnmFQ nCf1H+dyyUSPEUK87HgXeE2H1FLa2Q6wnIt4LOxqiK4SKekmH0DS1U4Ig50qqpt2Z7hG P1XQ==
X-Gm-Message-State: AOAM532Wp0E9hPx25PUpUI8jeM2zom2IV8TGBs/ihyF2BmLJvITkm4iP 2kG+NGR+iYBSO5JBzKS80N/jZd1nxva6bUs+O0oIwA==
X-Google-Smtp-Source: ABdhPJxfHl8tNP5VKzibb0TXXZOu1SuMd5btZ+23LzfkBb0DdFDMG67tquKTbb2xrM9+821FtQIkPt7508un4lC9/w4=
X-Received: by 2002:a1c:2bc1:: with SMTP id r184mr19302994wmr.133.1595814955397; Sun, 26 Jul 2020 18:55:55 -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> <CAD9ie-uzNKRaY8XVwEjVppC_c5q+3c+8vh3jydJGiqUgfF8N=w@mail.gmail.com> <E71079E8-A277-431C-A083-B224C5106178@mit.edu> <CAK2Cwb5b=swDm1ob+OF0-8a=2QsK5_UvNPb8hYvLY+ZHjEuQ+w@mail.gmail.com> <CAOW4vyNH=aZ+Piw=_tT+6ibmQ2Ct=ayeKZuW5ba7=X7vAqtv_A@mail.gmail.com> <CAD9ie-sB_SzwNGc0C8cD+C8irEugBRxoH-D+PY_apO=hWG5QYw@mail.gmail.com> <CAK2Cwb4fk4HDBH332NhdkuTQBe9f477X9SF1oxDN-vG24Lpnww@mail.gmail.com>
In-Reply-To: <CAK2Cwb4fk4HDBH332NhdkuTQBe9f477X9SF1oxDN-vG24Lpnww@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Sun, 26 Jul 2020 21:55:44 -0400
Message-ID: <CAOW4vyM3r-v7UFWMArkbdriUUTezRi8bAYuta=mUtfZ1sZZ1TA@mail.gmail.com>
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Dick Hardt <dick.hardt@gmail.com>, Justin Richer <jricher@mit.edu>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Fabien Imbault <fabien.imbault@gmail.com>, Mike Varley <mike.varley@securekey.com>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008b479a05ab629f28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/B2otdDYq8UCzgDSpYox8joPP45c>
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: Mon, 27 Jul 2020 01:56:02 -0000

+1 Tom's input.

This discussion about Key Handle vs. client id & handle wouldn't exist if
GNAP had the notion of TF defining how the GS/RS/Clients identify
and authenticate each other.

A simple TF can describe the standard case (happy path) without having to
foresee all eventualities.

A GNAP profile will also be simple as it will keep out everything else
(e.g. US Healthcare, PSD2).

BR
/Francis


On Sun, Jul 26, 2020 at 9:43 PM Tom Jones <thomasclinganjones@gmail.com>
wrote:

> You should consider a trust framework to be first of all a set of
> qualifying criteria above and beyond the literal meaning of the standard.
> Ours is focused on US Healthcare, but lots of others make sense. The
> international R&E org is the basis for the openid federation doc.
> Secondarily the trust framework could vet members so that they made
> affirmative statements about their compliance.
> Tertiary they tf could mandate testing of the members. That is the case
> for US Healthcare.
> the tf could be blank for sites with no moral scruples whatsoever. (the
> majority of sites i am sure.)
> Peace ..tom
>
>
> On Sun, Jul 26, 2020 at 6:18 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
>> Hi Francis
>>
>> While a Trust Framework concept looks to make sense for PSD2 use cases,
>> there are lots of other use cases.
>>
>> How would you see existing OAuth 2 and OIDC concepts fitting into a Trust
>> Framework concept?
>>
>> /Dick
>>
>> ᐧ
>>
>> On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha <fpo@adorsys.de> wrote:
>>
>>> I just read through some work being done by Tom at the FIRE (Federated
>>> Identifiers for Resilient Ecosystems) working group and it confirms my
>>> intention of suggesting the consideration of a "Trust Framework" as a
>>> context defining how to handle the client_id.
>>>
>>> The procedure the GS applies to trust a client is derived from the
>>> "Trust Framework" that governs the environment in which GS and Client are
>>> operating.
>>>
>>> In the European PSD2 ecosystem, National Country Authorities (a.k.a
>>> Market Authorities or Regulators):
>>> - delegate the production of client certificates to Trust Service
>>> Providers (TSPs). TSPs are known certification authorities (CAs) in the
>>> corresponding countries.
>>> - maintain a register of Certified Third Party Providers (TPPs) at the
>>> European Banking Association (EBA), where the validity of the TPP license
>>> can be verified, in addition to the client certificate.
>>>
>>> Designing an authorization framework around the PSD2 ecosystem, there is
>>> no need to maintain any static or dynamic client_id. Each request is
>>> associated with an SSL client certificate called QWAC (Qualified Website
>>> Assertion Certificate).
>>> - This certificate can be verified as the GS maintains a list of all
>>> known TSP's CA authorized to release PSD2 client certificates.
>>> - This certificate also contains the list of roles assigned to the TPP
>>> by the regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI
>>> (account information), PSP_IC (card) sufficient for the client access
>>> control in the PSD2 trust framework.
>>> - This certificate contains a permanent "Competent Authority" that
>>> uniquely identifies the NCA issuing the TPP license.
>>> - This certificate contains a permanent "Authorization Number" that is
>>> unique in the context of the NCA.
>>> - so AuthorizationNumber@CompetentAuthority is globally unique in the
>>> context of the PSD2 trust framework.
>>>
>>> Given these facts, GS implementing PSD2 do not need to register clients.
>>> - Each request of the client to the GS can be mTLS secured using the
>>> QWAC.
>>> - GS can extract all information needed to perform authorization from
>>> that certificate.
>>>
>>> This use case does not need an extra client_id at the protocol level.
>>>
>>> This is:
>>> - based on the experience we are making implementing PSD2,
>>> - based on my reading Tom's FIRE use case in the health sector on the
>>> sharing of Patient Health Information (PHI) among health care providers,
>>>
>>> I suggest GNAP introduces the notion of "Trust framework" that governs
>>> the environment in which RS, GS and Client interoperate. We can then
>>> delegate the decision on specifying the necessity and functions of a
>>> client_id to the trust framework.
>>>
>>>
>>> On Thu, Jul 16, 2020 at 7:58 PM Tom Jones <thomasclinganjones@gmail.com>
>>> wrote:
>>>
>>>> I have been working on different level s of identifier, but from the
>>>> mobile app perspective. That's the hardest case as you need to boot strap
>>>> trust. I suspect that in the web site case you will need these levels.
>>>> Transport, application, real world.
>>>>
>>>> If anyone wants to work on these, let me know and I'll get you the
>>>> links in Kantara.
>>>>
>>>> thx ..Tom (mobile)
>>>>
>>>> On Thu, Jul 16, 2020, 2:47 PM Justin Richer <jricher@mit.edu> wrote:
>>>>
>>>>> For all of these, I still say we should have different levels of
>>>>> identifier. A “client ID” should identify the client, and not be used as a
>>>>> stand-in for other things.
>>>>>
>>>>> Off the top of my head I think we might want to have identifiers,
>>>>> assertions, proofs, and other trust-binding items for:
>>>>>
>>>>>  - Organizations
>>>>>  - Devices
>>>>>  - Software applications
>>>>>  - Software instances
>>>>>  - Software versions
>>>>>
>>>>> So if we’re going to talk about identifying these aspects, we should
>>>>> tackle each as its own thing and not mush it all into “client_id”. That
>>>>> way, hopefully, GNAP can have a much better idea what a “client” is than
>>>>> OAuth 2 currently does.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> On Jul 16, 2020, at 4:34 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>>
>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> 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
>>>>
>>>
>>>
>>> --
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead
>>> adorsys GmbH & Co. KG
>>> https://adorsys-platform.de/solutions/
>>>
>>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/