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

From: Mike Varley <[email-masked]>
Date: Tue, 14 Jul 2020 17:54:26 +0000

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 <[email-masked]> on behalf of Mike Jones <Michael.Jones=[email-masked]>
Date: Tuesday, July 14, 2020 at 12:18 PM
To: Dick Hardt <[email-masked]>, "[email-masked]" <[email-masked]>, Justin Richer <[email-masked]>
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.

                                                       -- Mike

From: Dick Hardt <[email-masked]>
Sent: Friday, July 10, 2020 1:17 PM
To: [email-masked]; Justin Richer <[email-masked]>; Mike Jones <[email-masked]>
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.

---

From: Justin Richer <[email-masked]>
Date: Tue, 14 Jul 2020 15:31:31 -0400

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 <[email-masked]> wrote:
> 
> From: Txauth <[email-masked] <mailto:[email-masked]>> on behalf of Mike Jones <Michael.Jones=[email-masked] <mailto:Michael.Jones=[email-masked]>>
> To: Dick Hardt <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Justin Richer <[email-masked] <mailto:[email-masked]>>
> 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 <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 <[email-masked] <mailto:[email-masked]>> 
> To: [email-masked] <mailto:[email-masked]>; Justin Richer <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 14 Jul 2020 11:53:17 -0700

(changing subject to reflect topic)

In my opinion, client registration is in scope.

In both XYZ and XAuth, the client can provide some information about
itself, and get back an ID it can use in subsequent calls. No one has said
that should NOT be in scope so far.

Myself, I do support adding other mechanisms for a Client to share
information about itself with an AS such as software statements, or a URI
that binds a URI to information retrieved from that URI, and to the Client.

I agree that we don't want to define software statements per se, but we
should refer to some standards so that interop between clients and ASs.

/Dick

On Tue, Jul 14, 2020 at 10:54 AM Mike Varley <[email-masked]>
wrote:

> 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.
>
>
>
> 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)
>
> 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 <[email-masked]> on behalf of Mike Jones
> <Michael.Jones=[email-masked]>
> *Date: *Tuesday, July 14, 2020 at 12:18 PM
> *To: *Dick Hardt <[email-masked]>, "[email-masked]" <
> [email-masked]>, Justin Richer <[email-masked]>
> *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
> .
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Dick Hardt <[email-masked]>
> *Sent:* Friday, July 10, 2020 1:17 PM
> *To:* [email-masked]; Justin Richer <[email-masked]>; Mike Jones <
> [email-masked]>
> *Subject:* Key handle vs client id & handle
>
>
>
> 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.
>
>
>
> 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.
>
ᐧ

---

From: Tom Jones <[email-masked]>
Date: Tue, 14 Jul 2020 16:25:18 -0700

I suggested earlier to use the entity statement of the Openid federation
spec, but heard no feedback. Why not?

thx ..Tom (mobile)

On Tue, Jul 14, 2020, 1:00 PM Dick Hardt <[email-masked]> wrote:

>> 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.
>>
>>
>>
>> System A can be unknown to the AS but can dynamically registered each
>> time with an appropriate software statement
>>
>> *To:* txauth@ietf..org <[email-masked]>; Justin Richer <[email-masked]>;
>> Mike Jones <[email-masked]>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Mike Varley <[email-masked]>
Date: Wed, 15 Jul 2020 14:35:14 +0000

Hi Tom,
I think the group is still aligning on the concept, and the entity statement is a mechanism (and likely an appropriate one) but we just haven’t gotten there yet.

I think the next question (once we agree there is a requirement for this type of assertion for clients) is what type of assertions may need to be supported…

MV

From: Tom Jones <[email-masked]>
Date: Tuesday, July 14, 2020 at 7:25 PM
To: Dick Hardt <[email-masked]>
Cc: Mike Varley <[email-masked]>, Mike Jones <Michael.Jones=[email-masked]>, Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] Client Registration (Was: Key handle vs client id & handle

I suggested earlier to use the entity statement of the Openid federation spec, but heard no feedback. Why not?
thx ..Tom (mobile)

On Tue, Jul 14, 2020, 1:00 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
(changing subject to reflect topic)

In both XYZ and XAuth, the client can provide some information about itself, and get back an ID it can use in subsequent calls. No one has said that should NOT be in scope so far.

Myself, I do support adding other mechanisms for a Client to share information about itself with an AS such as software statements, or a URI that binds a URI to information retrieved from that URI, and to the Client.

I agree that we don't want to define software statements per se, but we should refer to some standards so that interop between clients and ASs.

/Dick

On Tue, Jul 14, 2020 at 10:54 AM Mike Varley <[email-masked]<mailto:[email-masked]>> wrote:
Is client registration in scope for the protocol?

Thanks,

MV

From: Txauth <[email-masked]<mailto:[email-masked]>> on behalf of Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 14, 2020 at 12:18 PM
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Txauth] Key handle vs client id & handle

                                                       -- Mike

From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 10, 2020 1:17 PM
To: txauth@ietf..org<mailto:[email-masked]>; Justin Richer <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>
Subject: Key handle vs client id & handle

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.
[Image removed by sender.]ᐧ
--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 16 Jul 2020 09:49:31 +0200

+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 <[email-masked]> 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
>
> *From: *Txauth <[email-masked]> on behalf of Mike Jones <
> Michael.Jones=[email-masked]>
> <https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc..section.9.1>
> .
>
>                                                        -- Mike
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jul 2020 11:24:40 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 14, 2020, at 1:54 PM, Mike Varley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 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 <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
>>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 16 Jul 2020 11:00:17 -0700

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 <[email-masked]> 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
>
>> 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.
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jul 2020 16:08:05 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> +1 on that.
>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 16 Jul 2020 13:34:23 -0700

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 <[email-masked]> 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
>
> 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
>> 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.
>>
>>> 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
>>> 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)
>>> And even ‘StatelessAS’ can operate by never storing client IDs because
>>> it will always just rely on the software statements.
>>>
>>> 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.
>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jul 2020 17:46:52 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 16, 2020, at 2:00 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Justin, 
>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 16 Jul 2020 16:57:39 -0700

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 <[email-masked]> 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
>
> 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.
>
>
> ᐧ
>
>>>> 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
>>>> 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
>>>> System C can pre-register with the AS for a client ID because it
>>>> doesn’t deal with software statements etc…
>>>> …
>>>> I think a client registration protocol that allows these scenarios
>>>> would be very useful in GNAP, but hopefully avoiding having to define what
>>>> <https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc...section.9.1>
>>>> .
>>>>
>>>>                                                        -- Mike
>>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Sat, 25 Jul 2020 23:41:10 -0400

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 <[email-masked]>
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)
>
>>> Organization A writes client software that calls resources managed by
>>> the AS in Organization B. The client_id represents Organization A to
>>> same, because they are not..
>>>
>>>
>>>
>>>
>>>
>>>
>>>>> 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.
>>>>>
>>>>> We should also be thinking about how to include what the OpenID
>>>>> Connect Federation spec
>>>>> There are potentially some significant differences between a
>>>>> registered client, and a dynamic client to an AS.
>>>>>
>>>>> 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.
>>>>>

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

---

From: Dick Hardt <[email-masked]>
Date: Sun, 26 Jul 2020 18:18:22 -0700

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 <[email-masked]> wrote:

> - delegate the production of client certificates to Trust Service
> Providers (TSPs). TSPs are known certification authorities (CAs) in the
> corresponding countries.
> Designing an authorization framework around the PSD2 ecosystem, there is
> no need to maintain any static or dynamic client_id. Each request is
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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..
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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
>>>>>
>>>>>> 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
>>>>>> 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)
>>>>>> And even ‘StatelessAS’ can operate by never storing client IDs
>>>>>> because it will always just rely on the software statements.
>>>>>>
>>>>>> 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

---

From: Tom Jones <[email-masked]>
Date: Sun, 26 Jul 2020 18:43:20 -0700

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 <[email-masked]> wrote:

>> In the European PSD2 ecosystem, National Country Authorities (a.k.a
>> Market Authorities or Regulators):
>> - This certificate can be verified as the GS maintains a list of all
>> known TSP's CA authorized to release PSD2 client certificates.
>> - GS can extract all information needed to perform authorization from
>> that certificate.
>>
>> 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.
>>
>>
>>>>> 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
>>>>>
>>>>> *instance* of the software, but we also don't want to force clients
>>>>> to all be treated the same, because they are not..
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> System A can be unknown to the AS but can dynamically registered
>>>>>>> each time with an appropriate software statement
>>>>>>> I agree that there are significant differences between statically
>>>>>>> and dynamically registered clients and that’s appropriate to be able to

---

From: Francis Pouatcha <[email-masked]>
Date: Sun, 26 Jul 2020 21:55:44 -0400

+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 <[email-masked]>
wrote:

> Tertiary they tf could mandate testing of the members. That is the case
> for US Healthcare.
>>> 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.
>>>
>>> - 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.
>>>> If anyone wants to work on these, let me know and I'll get you the
>>>> links in Kantara.
>>>>
>>>> thx ..Tom (mobile)
>>>>
>>>>> 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
>>>>>>>> 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
>>>>>>>>
>>>>>>>> *To:* [email-masked]; Justin Richer <[email-masked]>; Mike Jones
>>>>>>>> <[email-masked]>

---

From: Tom Jones <[email-masked]>
Date: Sun, 26 Jul 2020 19:15:23 -0700

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 <[email-masked]> wrote:

>>> How would you see existing OAuth 2 and OIDC concepts fitting into a
>>> Trust Framework concept?
>>>
>>> /Dick
>>>
>>> ᐧ
>>>
>>>> Designing an authorization framework around the PSD2 ecosystem, there
>>>> is no need to maintain any static or dynamic client_id. Each request is
>>>>>>> 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
>>>>>>> Organization A writes client software that calls resources managed
>>>>>>> by the AS in Organization B. The client_id represents Organization A to
>>>>>>>> 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
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> *To:* [email-masked]; Justin Richer <[email-masked]>; Mike
>>>>>>>>> Jones <[email-masked]>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Mon, 27 Jul 2020 07:16:47 -0400

+1. There are a lot of use cases where the client isn’t identified using an identifier known to the AS. OAuth/OIDC don’t fit very well in those use cases because the protocol :requires: a client_id. That’s why we get things like the OIDC Federation clever “inline registration” and SIOP that both add semantics to a required field that they don’t need for its original purpose.

What I’m arguing is that we shouldn’t :require: a client_id, but we can :allow: its equivalent for an AS that supports it. If you have an identifier known to the AS and that identifier is presented along with some trusted material (like the proof of a key via signature, for instance), then that is a subset of what can be trusted and why. And what you’re identifying, ultimately, is the key being presented. All other cases of identifying the “client” separate from its key material are actually presenting other forms of trust and shouldn’t be conflated with an all-present client identifier. 

I agree that fundamentally a trust framework is the way to look at it: the AS needs to decide if it trusts the entity making the call to start a request, and what it trusts that entity to do. Identification of that entity by some known value is a subset of what is possible by trust frameworks.

 — Justin

> On Jul 26, 2020, at 10:15 PM, Tom Jones <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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.
> 
> - GS can extract all information needed to perform authorization from that certificate.
> 
> - 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 16, 2020, at 4:34 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 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.. 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>>> 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 <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
>>>>>  
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>
> 
> -- 
> Francis Pouatcha
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>