Adding Human Rights Considerations

draft-ietf-gnap-core-protocol.md

@@ -5602,6 +5602,52 @@ it is not usually feasible to provide notification and warning to someone before
 needs to be executed, as is the case with redirection URLs. As such, SSRF is somewhat more difficult
 to manage at runtime, and systems should generally refuse to fetch a URI if unsure.
 
+# Human Rights Considerations {#human-rights}
+
+Human rights considerations are different form from privacy considerations to the extent they are universal and cannot be regulated or consented away. *A fundamental protocol such as GNAP must therefore support human rights by default and not as an option or extension.* The human rights considerations in this section are modeled after the list of privacy threats in [RFC8280](https://datatracker.ietf.org/doc/html/rfc8280), "Research into Human Rights Protocol Considerations" and the most recent draft of [Freedom of Association on the Internet](https://www.ietf.org/archive/id/draft-irtf-hrpc-association-10.html). Although there is no human right specific to delegated authorization, in the IETF context we are using the work of HRPC and IRTF on [freedom of association and assembly](https://www.ietf.org/archive/id/draft-irtf-hrpc-association-10.html#section-4) (FAA) for the purpose of risk analysis and suggested mitigations. 
+
+The GNAP specification supports human rights by allowing users to freely associate with delegates while ensuring interoperability at the RS and AS. 
+
+## Can GNAP Promote Freedom of Association and Assembly?
+
+OAuth and related protocols like OpenID Connect have contributed to global platform oligopolies that are difficult to regulate and, when pressed, collaborate with governments that do not honor universal human rights. This unintended consequence of authorization design is due to a combination of resource server autonomy and resource user convenience. Resource servers, if allowed, will do as much surveillance as they can get away with or outsource that surveillance to platform intermediaries in exchange for a reduced operating cost. For their part, users will, almost without exception, choose the most convenient path to resource access even when that path exposes them to secondary costs or poorly understood risks. 
+
+It is therefore now common practice for a resource server to align its interest with an authorization server and often an identity provider as well. For example, a network effect ensues when a social network offers users "free" resource processing as long as they are also party to the resource control function and, for the most successful social networks, trusted as identity providers.
+
+Requiring the resource owner to share their policies with a resource controller they can't choose is a violation of human rights through forced association. A well-understood non-digital example is "forced arbitration" clauses where the powerful service provider gets to choose the arbitrator. In addition to forced policy sharing, giving the mandated controller access to user requests enables unwarranted surveillance and is an impediment to freedom of assembly. As with OAuth2 and UMA2, GNAP offers implementers of a resource server the choice to support freedom of assembly and association, but experience teaches us that resource servers will hardly ever make that choice unless it's core to the protocol's interoperability and user experience design. 
+
+By way of mitigation, GNAP allows the RS to choose their AS as controller but also allows the RO to choose _their_ intermediary to for processing resource requests. This intermediary could be a fiduciary or a community unrelated to and untrusted by either the AS or RS.
+
+As discussed below, delegation should also support attentuation and GNAP supports attenuation through either directly by token design or indirectly through token exchange at the AS.
+
+## Resource Server Delegation without Attenuation
+
+GNAP gives the resource server a choice of authorization token formats but GNAP tokens don't have to support attenuated delegation. Without the capacity for attenuation, a resource owner is forced, in the human rights sense, to make a choice between sharing attenuation policies with a request processor they did not freely choose or granting unattenuated access to requesting parties through impersonation. This compromises human rights through forced surveillance and compromises security through a lack of accountability.
+
+When attenuated delegation is not supported by the authorization token format, mitigation in GNAP requires the AS to operate a token exchange that users can access to request an attenuated token. For accountability, the AS can require and log a public key or its equivalent as authenticated by the requesting party along with the desired scope of the new token. Note that the public key or similar user designation need not be meaningful to the RS or its AS.  It only needs to be meaningful to the delegator in cases where security has been compromised.
+
+A second problem arises when the RO wants to have different agents for different policies, e.g., one agent for monitoring financial accounts and another agent for doing transactions.  Without attenuated delegation the RO has to give all permissions to both agents, a clear violation of the Principle of Least Privilege. It is also a privacy violation, since the party that needs fewer permissions learns that the RO has more. This problem can be addressed by giving the RO a separate capability for each scope on each resource, but that is not in the current specification.  The result will be incompatible implementations.
+
+## Resource Server Delegation with Attenuation
+
+When a GNAP resource server provides capabilities that support attenuation the resource owner can use that capability directly or the owner can delegate some of that capapbility to an agent that they choose. This mitigation avoids the forced association problem but it is effective in the real-world sense only if this is also the most convenient choice.
+
+Aligning the incentives for FAA means that GNAP MUST or SHOULD require resource servers to support attenuated delegation and do so in a way that is interoperable across any chosen GNAP-labeled authorization server. A real-world example would be open banking regulations that separate the choice of bank as resource server from the choice of payment processor (e.g. credit card) as authorization server. 
+
+## Interoperability Across Resource and Authorization Servers
+
+Optionality in authorization token formats can again result in platform network effects as the cost and complexity of authorization servers drives smaller delegates out of the market. One source of confusion for a delegated authorization protocol is failure to separate the concerns of three classes of implementers: the RS/AS, Client, and the user agent.
+
+1 - RS / AS implemeneters should be interoperable with all end user clients. Client credentials are a weak and, in the Zero-Trust Architecture sense, an unacceptable substitute for user authentication. 
+
+2 - RS and AS can add value by publishing their scope options and other client features with respect for standards and without resorting to client credential or idenitity methods that then drive centralization.
+
+3 - RS / AS should supprt user-centric or self-sovereign identity standards and log-keeping features and deprecate or give open choice of federation solutions that then contribute to platform solutions.
+
+4 - Client implementers should be able to assist the end user in making requests in an interoperable way regardless of whether those requests are to a RS, AS, or a delegate of the RO. Clients should be "untrusted by default" in all cases where the user does not have free choice to associate with that client. Clients that interoperate with secure and convenient (local biometric) authenticators via standards support this separation of concerns. 
+
+5 - User agent designers, as keepers of the user's policies, can offer policy support and automation of request processing. GNAP serves the delegation needs of both service providers and end users. GNAP must protect a user's right to choose how to store and apply their policies without forced association with a particular AS. 
+
 # Privacy Considerations {#privacy}
 
 The privacy considerations in this section are modeled after the list of privacy threats in {{RFC6973}}, "Privacy Considerations for Internet Protocols", and either explain how these threats are mitigated or advise how the threats relate to GNAP.
@@ -5629,7 +5675,7 @@ If the authorization server's implementation of access tokens is such that it re
 
 Several parties in the GNAP process are expected to persist data at least temporarily, if not semi-permanently, for the normal functioning of the system. If compromised, this could lead to exposure of sensitive information. This section documents the potentially sensitive information each party in GNAP is expected to store for normal operation. Naturally it is possible that any party is storing information for longer than technically necessary of the protocol mechanics (such as audit logs, etc).
 
-The authorization server is expected to store subject identifiers for users indefinitely, in order to be able to include them in the responses to clients. The authorization server is also expected to store client key identifiers associated with display information about the client such as its name and logo.
+The authorization server is expected to store subject identifiers for users indefinitely, in order to be able to include them in the responses to clients. The authorization server is also expected to store client key identifiers associated with display information about the client such as its name and logo. The authorization server is also expected to store policies that it evaluates requests against. These policies may be specific and confidential to the owner of the resource under control.
 
 The client is expected to store its client instance key indefinitely, in order to authenticate to the authorization server for the normal functioning of the GNAP flows. Additionally, the client will be temporarily storing artifacts issued by the authorization server during a flow, and these artifacts SHOULD be discarded by the client when the transaction is complete.