Change Details

Admin whitelists client so that users do not have to accept the authorization dialog every time they login. **Priority:** Optional **Acceptance Criteria:** In T229508 and T229509, the user is not presented with an authorization dialog at step 3 and the workflow continues as if the user had authorized the server.

Admin whitelists client so that users do not have to give consent to share profile information every time they login. This feature must be controlled by a configuration flag which would default to not allowing whitelisting. If whitelisting is enabled on a wiki that is providing authentication, then client admins would be able to specify if the client should be whitelisted when registering the client with the wiki or editing the client's OAuth configuration for the wiki. If a client is thus whitelisted, users who are authenticating with the client would not be presented with the consent dialog from the wiki during the authentication process. Note that this is not a desirable feature for a public wiki used for authentication with untrusted clients, since it can cause information leakage of user profile information to the clients. However, it is a very useful feature between trusted applications in an enterprise. **Priority:** Optional **Acceptance Criteria:** In T229508 and T229509, the user is not presented with an authorization dialog at step 3 and the workflow continues as if the user had authorized the server.

Admin whitelists client so that users do not have to accept the authorization dialog every time they logingive consent to share profile information every time they login. This feature must be controlled by a configuration flag which would default to not allowing whitelisting. If whitelisting is enabled on a wiki that is providing authentication, then client admins would be able to specify if the client should be whitelisted when registering the client with the wiki or editing the client's OAuth configuration for the wiki. If a client is thus whitelisted, users who are authenticating with the client would not be presented with the consent dialog from the wiki during the authentication process. Note that this is not a desirable feature for a public wiki used for authentication with untrusted clients, since it can cause information leakage of user profile information to the clients. However, it is a very useful feature between trusted applications in an enterprise. **Priority:** Optional **Acceptance Criteria:** In T229508 and T229509, the user is not presented with an authorization dialog at step 3 and the workflow continues as if the user had authorized the server.