user should be able to choose

phase-2/osw-abstract.md

@@ -1,6 +1,6 @@
 In Research and eduction (R&E) we see new standards evolving (e.g. in AARC https://aarc-project.eu) that address the use-cases that are particularly relevant in that environment, and that are not addressed by existing OAuth standards. This is linked to a move away from authentication mechanisms like password, SSH keys and X.509 towards token based authentication. In R&E we see that the organisations in control of the various resource servers and clients work together in communities. These communities run an authorization server and manage trust and authorization policies. 
 In this context we see that the authorization server does not have detailed knowledge of the resources and access modes that a resource server can offer, and thus is not well-placed to present a scope selection GUI that goes beyond using a generic description of the scope. This is a problem for use-cases where more fine-grained control over the level of access is required. E.g. granting access to a specific folder on a storage server, or granting access to a specific computing resource and that cannot be solved by establishing a list of generic scopes.
-Another usecase that we want to address is where there are several resource servers that offer a similar service using the same protocol, e.g. a storage server that offers WebDAV access to files. In this case, the client should be able to choose the resource server that it wants to access, and the client should not have to know about the resource servers in advance.
+Another usecase that we want to address is where there are several resource servers that offer a similar service using the same protocol, e.g. a storage server that offers WebDAV access to files. In this case, the user should be able to choose the resource server that it wants to access, and the client should not have to know about the resource servers in advance.
 We aim for a solution that does not require changes to existing resources servers, and that will work with existing OAuth clients. We expect that our solution will be of interest to other communities that have similar requirements, where the authorization server and resource server are developed by different entities. 
 
 We considered using the Lodging Intent Pattern, a "pre-dance" where the client first obtains a structured scope before initiating the main OAuth dance, but we rejected this approach because it creates an undesirable many-to-many relationship between clients and the specific resource servers. Instead, we want to hide the resource server behind the authorization server which acts as a trusted broker between the various clients of various the organisations and the various resource servers of various (other) organisations.