Change:
to update section 4 to provide an additional use case (RO's policy). I don't think we need to update the definitions or URL
To edit notification comments on pull requests, go to your .
NAME please run on this PR to clean up the line end spaces, otherwise looks good to me. Thanks!
will do ! (btw, I added that to the wiki)
Following the discussion on the mailing list, will plan a rewording to clarify URL Thanks for the feedback. There was a rewrite of section 4 (gathering consent and authorization) that sought to update this, so if that’s still not entirely clear that definitely needs another pass. — Justin >

Discussion:
The authorization and consent gathering process in GNAP is left deliberately flexible to allow for a wide variety of different deployments, interactions, and methodologies.  In this process, the <del> AS can gather consent from the RO as necessitated by the access that has been requested.  The AS can sometimes determine which RO needs to consent based on what has been requested by the client instance, such as a specific RS record, an identified user, or a request requiring specific access such as approval by an administrator.  If the AS has a means of contacting the RO directly, it could do so without involving the client instance in its consent gathering process.  For example, the AS could push a notification to a known RO and have the RO approve the pending request asynchronously.  These interactions can be through an interface of the AS itself (such as a hosted web page), through another application (such as something installed on the RO's device), through a messaging fabric, or any other means. When interacting with an RO, the AS can do anything it needs to determine the authorization of the requested grant, including: </del> <ins> AS can gather consent from the RO or apply the RO's policy as necessitated by the access that has been requested.  The AS can sometimes determine which RO needs to consent based on what has been requested by the client instance, such as a specific RS record, an identified user, or a request requiring specific access such as approval by an administrator.  If the AS has a means of contacting the RO directly, it could do so without involving the client instance in its consent gathering process.  For example, the AS could push a notification to a known RO and have the RO approve the pending request asynchronously.  These interactions can be through an interface of the AS itself (such as a hosted web page), through another application (such as something installed on the RO's device), through a messaging fabric, or any other means.  When interacting with an RO, the AS can do anything it needs to determine the authorization of the requested grant, including: </ins> authenticate the RO, through a local account or some other means such as federated login

Alternatively, the AS could require N of M possible RO's to approve a given request in order.  The AS could also determine that the end user is not the appropriate RO for a given request and reach out to <del> the appropriate RO asynchronously.  The details of determining which RO's are required for a given request are out of scope for this specification. </del> <ins> the appropriate RO asynchronously. The RO is also allowed to define a policy at the AS to determine which kind of end user can get access to the resource, and under which condition.  For instance, such a condition might require the end user login and the acceptance of the RO's legal provisions. Alternatively, client software could be acting without an end user, and the RO's policy allows issuance of access tokens to instances of that client software without human interaction. The details of determining which RO's or related policies are required for a given request are out of scope for this specification. </ins> The client instance can also indicate that it is capable of facilitating interaction with the end user, another party, or another