authorization code flow

phase-2/osw-abstract.md

@@ -5,4 +5,4 @@ We aim for a solution that does not require changes to existing resources server
 
 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.
 
-We therefore want to propose an OAuth extension which adds a "scope picker" service close to each resource server, to which the authorization server redirects the user in a "sub-dance", leaving the GUI of the authorization server generic and easy to maintain. This works as follows: using the standard authorization code flow, the client redirects the user to the authorization server. The client can request a specific resource server by including an audience, or it can use a scope to request a specific type of service (e.g. WebDAV). The authorization server then redirects the user to a well-known endpoint on the resource server's scope picker service based on the client's and user's preferences and applies any restrictions based on the communities' policy. The scope picker shows a GUI in which the user can select e.g. a folder and set the level from the ones they have access to and set the level of access (read, write) and builds a structured scope from this information. This structured scope is given a human-readable name, either suggested by the scope picker or chosen by the user. The scope picker then redirects the user back to the authorization server including all the scope information, which is then able to display the human-readable description in its GUI, even though the authorization server doesn't understand what it stands for. Optionally protocol specific information (e.g. the webdav URL to use) is returned to the authorization server, this is required because the client may not have knowledge about the resource server that the user selected. When the user then 'grants access' on the authorization server, the OAuth authorization scope dance is continued back to the client as normal. The client then can then use its access token to request the protocol specific information from the authorization server using a well-known endpoint on the authorization server and use it to access the resource server.
+We therefore want to propose an OAuth extension which adds a "scope picker" service close to each resource server, to which the authorization server redirects the user in a "sub-dance", leaving the GUI of the authorization server generic and easy to maintain. This works as follows: using the standard authorization code flow, the client redirects the user to the authorization server. The client can request a specific resource server by including an audience, or it can use a scope to request a specific type of service (e.g. WebDAV). The authorization server then redirects the user to a well-known endpoint on the resource server's scope picker service based on the client's and user's preferences and applies any restrictions based on the communities' policy. The scope picker shows a GUI in which the user can select e.g. a folder and set the level from the ones they have access to and set the level of access (read, write) and builds a structured scope from this information. This structured scope is given a human-readable name, either suggested by the scope picker or chosen by the user. The scope picker then redirects the user back to the authorization server including all the scope information, which is then able to display the human-readable description in its GUI, even though the authorization server doesn't understand what it stands for. Optionally protocol specific information (e.g. the webdav URL to use) is returned to the authorization server, this is required because the client may not have knowledge about the resource server that the user selected. When the user then 'grants access' on the authorization server, the OAuth authorization code flow is continued back to the client as normal. The client then can then use its access token to request the protocol specific information from the authorization server using a well-known endpoint on the authorization server and use it to access the resource server.