Human rights considerations

[fimbault]

See https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/431 and https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/434

as a starting point

[agropper]

Shouldn't the Human Rights Considerations section be in Core even if some of the mitigations are in RS?

[fimbault]

@agropper I think it really should be where the mitigations can be provided.

If we end up with some text that everyone agrees on (see related PR), what we could do is reference this section of the RS draft into the core spec (and is already done for some other parts).

[agropper]

I agree that the HRPC section should be where the mitigations can be provided, but there are at least three mitigations possible. A human rights consideration must be mitigated in a normative way so at least one of the mitigations has to be present for something to be called GNAP.

The mitigations I'm aware of are: 1 - The resource owner specifies the AS to the RS. Making this normative is deemed unrealistic by some. 2 - The resource owner is given a capability that can be attenuated by any AS specified by the RO. Making this normative changes some of the RS-first flows. 3 - The GNAP AS specified by the resource owner is able to perform a token exchange with any other GNAP AS. The RS would not be aware the difference.

[fimbault]

Yes, I've only discussed 2 and 3 based on your input.

1 seems quite hard to achieve in practice : it presupposes that the RO is actively able to influence the design and run of the service it's using.

[agropper]

Human rights are seldom implemented by powerful resource servers without external "influence".

The design "influence" we're talking about is the difference between a resource server account being linked to a RO's identity or an RO's AS. Either way, the RS has to store at least one RO-specified datum as part of the account provisioning process. The rest of the design and run is what GNAP is about and the difference between GNAP and OAuth.

[jricher]

I disagree with @agropper 's classification of the model. The RS might not have any clue about an "account" or "identity" of the RO. The RS is merely protecting a resource, it's the AS that does the mapping between identities and access rights.

[agropper]

With @jricher's definition, the RS has no notion of an RO and can't differentiate end users or be subject to audit based on that difference. But the RS and RO each have policies to enforce. The RS policies tend to be regulatory or business-driven as with export restrictions or DDoS mitigation. The RO policies mostly concern privacy or paywalls and are therefore focused on end-users other than the RO themselves.

Is GNAP saying that the AS has access to and evaluates both the RS and RO policies by design?

[jricher]

No, GNAP is saying that the AS evaluates the RO's policies and translates them to something that the RS's policies can enforce. The RS will probably never see the RO's policies. The RO never directly interacts with the RS, but rather with the AS. A lot of the regulatory requirements that you're describing would be encoded and enforced, in total, by an AS+RS combination, and not the RS alone.

[fimbault]

I agree with what you say @jricher and that was my reason for how the considerations are stated (but probably it can be improved). IMHO the fact that in many situations the RS doesn't know the RO policies doesn't diminish the responsability it takes by delegating to the AS.

[agropper]

The human rights consideration is forced association of RO and AS. As an RO, I do not want to be forced to share policies and allow traffic analysis by an entity that I can't choose.

The RS+AS pair is typically happy to take responsibility for enforcing the RO policies because it's the basis for customer lock-in and platform scaling. This is what happened with OAuth. Why must we allow the same to happen with GNAP?

Current regulatory practice like GDPR and OpenBanking is based on separating controller (AS) from processor (AS) so that the RO can substitute an AS without also changing the RS and vice-versa. This, by definition, requires the AS-RS link to be standardized AND it may require regulatory action as well. GNAP can help the regulators by making the choice of AS a SHOULD.

Making RO+AS a SHOULD does not prevent RS+AS in some cases. What it does is take the regulatory capture issue out of band into the policy / regulatory domain where it belongs.

[jricher]

Every OpenBanking system that I am familiar with does not separate the AS from the RS, but rather the Client from the AS+RS pairing, and ensures that the AS will allow a new client instance (in GNAP parlance) to access things. I highly doubt you'll find a bank willing to outsource its AS functionality, let alone successfully argue that doing so is actually good for security of the consumer.

As the RO, all I care about is that I can access my bank account information from my bank. I have an account at the AS (my bank) to protect my account (also my bank) and I can use that account (as the RO) to get my account information into the application of my choice (the client).

[agropper]

We seem to be talking past each other. Requests go to an AS, not a client. The AS has the policies and can do surveillance. Delegation is almost meaningless without choice. If the choice of delegate is denied to the RO then we’re talking away a basic human right of the RO. That’s the violation I’m raising.

The considerations discussion seems to be about why we “have to” deny the RO the choice of delegate. There are at least three ways for GNAP to enable RO choice of AS without denying the RS the opportunity to also enforce their policies.

On Mon, Oct 31, 2022 at 10:22 PM Justin Richer @.***> wrote:

Every OpenBanking system that I am familiar with does not separate the AS from the RS, but rather the Client from the AS+RS pairing, and ensures that the AS will allow a new client instance (in GNAP parlance) to access things. I highly doubt you'll find a bank willing to outsource its AS functionality, let alone successfully argue that doing so is actually good for security of the consumer.

As the RO, all I care about is that I can access my bank account information from my bank. I have an account at the AS (my bank) to protect my account (also my bank) and I can use that account (as the RO) to get my account information into the application of my choice (the client).

— Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/54#issuecomment-1297933049, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YIHPFO5QD76OG7NQHTWGB5FNANCNFSM6AAAAAAREMCR24 . You are receiving this because you were mentioned.Message ID: @.***>

[fimbault]

In my proposal I didn't want to go as far as making the relationship a SHOULD, because there are so many different situations (also dependant on market forces) that aren't forced association but legitimate use cases (as in openbanking etc.). Calling out the risk is I believe adding value so that responsible implementers can think to the way they need to approach this issue for their specific case.

[agropper]

There's a balance between vendor lock-in on the AS+RS side and added implementation cost in the AS+RO side. The vendor lock-in effect is clear while the added cost of implementing RO choice is not well understood.

How do we strike this balance? Given a choice, would any customer choose an RS that did not use GNAP to offer a choice of AS? Given a choice, would any consumer protection regulator forego the option of a more open API model?

In a general sense, almost all consumer protections including seat belts and energy-efficient homes are initially resisted by RSs for all sorts of business reasons. But once the technology is available, visible, and widely accessible the benefits are clear enough that regulations are no longer needed. GNAP is the post-OAuth technology that can enable effective consumer and societal protection of everything from social media to machine learning platforms. Without the SHOULD, the distinction between vendor lock-in and decentralized governance will be invisible to consumers just like Dynamic Client Registration is invisible today.

On Tue, Nov 1, 2022 at 10:06 AM Fabien @.***> wrote:

In my proposal I didn't want to go as far as making the relationship a SHOULD, because there are so many different situations (also dependant on market forces) that aren't forced association but legitimate use cases (as in openbanking etc.). Calling out the risk is I believe adding value so that responsible implementers can think to the way they need to approach this issue for their specific case.

— Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/54#issuecomment-1298562854, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YMOLZ2WBVJIUCXGT7TWGEPWJANCNFSM6AAAAAAREMCR24 . You are receiving this because you were mentioned.Message ID: @.***>

[fimbault]

One practical use case that's coming is passkeys. While that's great for usability, there's a looming threat that operating systems and browser vendors will control the entire authN ecosystem. I think GNAP can be an important piece to keep the ecosystem open.

[agropper]

Fabien, Your perspective makes me smile because Justin and I were both in the passkey session here at IIW 35.

My interpretation of your comment below matches an example I used in another IIW session, that one on AI. My example was the opportunity to regulate (or voluntarily offer) that the steering and LIDAR APIs in a self-driving car SHOULD be exposed in order for the passenger to plug-in a Tesla AI into the Ford car they are using. This avoidance of lock-in by the car manufacturer as RS benefits everyone, maybe even the RS themselves, once in place as the basis for competition.

On Wed, Nov 16, 2022 at 1:04 AM Fabien @.***> wrote:

One practical use case that's coming is passkeys. While that's great for usability, there's a looming threat that operating systems and browser vendors will control the entire authN ecosystem. I think GNAP can be an important piece to keep the ecosystem open.

— Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/54#issuecomment-1316640361, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJ7UCYYP774SZDD4BDWISPSPANCNFSM6AAAAAAREMCR24 . You are receiving this because you were mentioned.Message ID: @.***>

[fimbault]

It is indeed in the interest of the RS in your car example (same with Google/Renault, in case the car manufacturer doesn't want to depend exclusively on Google for the access)

[agropper]

I’m not up on the Google/Renault relationship but it might not be what I’m suggesting with my hypothetical Ford and Tesla example. If, for example, Ford or Renault did not have the resources to develop the car control AI or other software and had to stay close to being a hardware manufacturer, then opening the API between them as RS and the software as AS might not make economic sense because they can get a better deal from Google by offering exclusivity rather than choice.

There are many examples of both patterns to be seen. Sometimes, as in Open Banking / PSD2, regulators have to step in. My point for GNAP is that regulators cannot presume to understand what’s possible from a security perspective unless the technology makes the best human rights or privacy practice the normative requirement.

On Wed, Nov 16, 2022 at 3:21 AM Fabien @.***> wrote:

It is in the interest of the RS in your car example (same with Google/Renault, in case the car manufacturer doesn't want to depend exclusively on Google for the access)

— Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/54#issuecomment-1316836574, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YK75GQR7UKPAWRPZULWIS7T3ANCNFSM6AAAAAAREMCR24 . You are receiving this because you were mentioned.Message ID: @.***>

[fimbault]

Yes, exclusivity (for some duration) is always a possibility. But then being technically without alternatives is yet another level of dependance.

Anyway, that was just an example, only based on public information and I don't pretend to speak for any of these companies.

[agropper]

Exclusivity is a good consideration in design of GNAP. Exclusivity is a regulatory concern. GNAP can make exclusivity explicit by forcing implementers to declare exclusivity as a policy decision rather than hiding behind exclusivity as a technical choice.

On Wed, Nov 16, 2022 at 7:43 AM Fabien @.***> wrote:

Yes, exclusivity (for some duration) is always a possibility. But then being technically without alternatives is yet another level of dependance.

Anyway, that was just an example, only based on public information and I don't pretend to speak for any of these companies.

— Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/54#issuecomment-1317222851, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJ3HMBWZPUWZ5AKZFTWIT6J5ANCNFSM6AAAAAAREMCR24 . You are receiving this because you were mentioned.Message ID: @.***>