Human rights considerations
fimbault opened this issue · 20 comments
See ietf-wg-gnap/gnap-core-protocol#431
and ietf-wg-gnap/gnap-core-protocol#434
as a starting point
Shouldn't the Human Rights Considerations section be in Core even if some of the mitigations are in RS?
@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).
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.
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.
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.
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.
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?
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.
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.
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.
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).
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.
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.
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)
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.