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

[Tom Jones <[e-mail]>]

one other tf could be "I am bound the terms of the GDPR".
If we go that way at all, I would also recommend a MUST or at least a
SHOULD "jurisdiction" field.
GNAP may as well take the moral high ground, it is pretty much empty space
right now.
Peace ..tom


On Sun, Jul 26, 2020 at 6:55 PM Francis Pouatcha <[e-mail]> wrote:

> +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 <[e-mail]>
> 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 <[e-mail]> 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 <[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/
>>>>
>>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>