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

[Dick Hardt <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>>> 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 <[e-mail]> on behalf of Mike Jones <
>>>>>> Michael.Jones=[e-mail]>
>>>>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>>>>> *To: *Dick Hardt <[e-mail]>, "[e-mail]" <
>>>>>> [e-mail]>, Justin Richer <[e-mail]>
>>>>>> *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 <[e-mail]>
>>>>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>>>>> *To:* [e-mail]; Justin Richer <[e-mail]>; Mike Jones <
>>>>>> [e-mail]>
>>>>>> *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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Txauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>