Update draft-ietf-gnap-core-protocol.md

draft-ietf-gnap-core-protocol.md

@@ -5606,29 +5606,31 @@ to manage at runtime, and systems should generally refuse to fetch a URI if unsu
 
 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 choose their delegates through interoperability at the RS and AS. 
+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 their 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.
+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.
 
-Effectively, the imposition of a an intemediary controller of a resource is a violation of human rights through forced association. The surveillance consequences of such imposition 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. 
+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 still allows the RS to choose their AS as intermediary controller but also allows the RO to choose _their_ intermediary to for processing resourc requests. This intermediary could be a fiduciary or a community unrelated to and untrusted by either the AS or RS. 
+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 authenticated by the requesting party along with the desired scope of the new token. Note that the public key or similar 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.
+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 authoriation server 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.
+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.