Merge branch 'master' of https://github.com/samuelgoto/WebID

consumers.md

@@ -136,38 +136,19 @@ Having said that, in the following section we'll enumerate some of the most prom
 
 We'll try to go over the thought process and the biggest considerations to be made starting from the most basic thing that we could do to some of the most involved.
 
-In each step, we'll try to go over some of the pros and cons. They can be introduced in the following order:
+The approaches are categorized into three general approaches:
 
 1. The [Permission-oriented](#the-permission-oriented-variation) Variation
 1. The [Mediation-oriented](#the-mediation-oriented-variation) Variation
 1. The [Delegation-oriented](#the-delegation-oriented-variation) Variation
-
-Lets go over each of these in that order.
 
 ## The Permission-oriented Variation
 
-The Permission-oriented APIs are a series of formulations where the browser tries to "get out of the way" as much as possible, letting IDPs drive as much as possible of the user experience.
-
-In this formulation, the browser gathers the user's permission and builds comprehension, but otherwise "gets out of the way" of IDPs.
+The simplest approach is to have WebID offer APIs that allow cross-origin data sharing for sign-in and authorization use cases that works much as they do today, but with the user agents providing warnings and consent moments to the user when new tracking risks appear.
 
 ![](static/mock19.svg)
 
-The two most meaningful permission moments a user would go through are:
-
-- Acknowledgement that the IDP will [be made aware](README.md#the-idp-tracking-problem) as you sign up and sign in to the relying parties.
-- Acknowledgement that the RP will [be made able to join](README.md#the-rp-tracking-problem) the user's identities with other relying parties.
-
-These prompts would be inserted by the browser before or after the IDP pass.
-
-The benefits of this approach are fairly clear: it gives IDPs the autonomy to cover their various use cases, differentiate between each other, innovate and compete, without the browser pulling them back.
-
-The drawbacks of this approach is that:
-
-- There would be three independent blocking permission moments: (a) one by the browser to capture the permission to allow the RP and the IDP to communicate, (b) one by the IDP to capture permission to sign-in with the RP and (c) one by the browser to capture the acknowledgement that RPs can track you when undirected identifiers are used.
-- The [The IDP Tracking Problem](README.md#the-idp-tracking-problem) and the [The RP Tracking Problem](README.md#the-rp-tracking-problem) are addressed via consent rather than mechanically. Because of the difficulty users have in comprehending the risks involved, there is a chance the permission moments will be as effective as "speed bumps" that users dismiss just to get them out of the way.
-- Because the IDP is controlling the user journey, the browser doesn't have the ability to promote directed identifiers as defaults (outside of policy).
-
-You can read more details about this variation [here](permission_oriented_api.md).
+An expanded exploration of this approach with its benefits and drawbacks can be seen [here](permission_oriented_api.md).
 
 Naturally, the next set of formulations try to address these two shortcomings at the cost of the autonomy of the IDP and the ossification of parts of the flow.
 

permission_oriented_api.md

@@ -11,23 +11,33 @@ updated: 08/10/2020
 The philosophy underlying this approach is that browsers should be responsible for ensuring user awareness and permission for cross-site interactions that create tracking risk, and outside of that Relying Parties and Identity Providers should have maximal control of the user experience.
 
 ## Permission flow properties
+
+## Preventing IDP tracking
 The intention is to prevent [IDP tracking](glossary.md#idp-tracking) by requiring a user gesture on the RP's page before the API can be invoked, and by displaying an appropriate dialog to the user before any identifying user information can be passed from the RP to the IDP. Both of these restrictions can be relaxed if the user agent knows that the user has successfully completed a sign-in with this RP and IDP before.
 
 This flow contains an implicit assumption that 'global' information (including the RP’s origin) can be shared with the IDP based on a user gesture on the RP page. Here 'global' means information that cannot be used to identify a specific user.
 
-In this flow the user agent attempts to mitigate RP tracking by displaying a warning if the IDP is going to provide correlatable user identifiers to the RP. The warning is not shown if the identifier is [verifiably directed](directed_identifiers.md#verifiably-directed-identifiers).
+## Preventing RP tracking
+In this flow the user agent attempts to mitigate [RP tracking](glossary.md#rp-tracking) by displaying a warning if the IDP is going to provide correlatable user identifiers to the RP. The warning is not shown if the identifier is [verifiably directed](directed_identifiers.md#verifiably-directed-identifiers).
 
+## User flow illustration
 ![](static/permission_based_flow.svg)
 
 ## Benefits
-* This should work well across a variety of protocols and use cases without user agents having to accommodate them specifically. 
+* This should work well across a variety of protocols and use cases without user agents having to accommodate them specifically.
+* For those reasons, IDPs and RPs can have control over sign-in experiences to improve user experiences as they see fit.
 * In cases where browser state is missing, the only experience downgrade is to have to agree to a cross-origin data sharing permission prompt again.
 
 ## Challenges
 * The user agent cannot differentiate cases where the IDP gave users the option to use directed identifiers but the user chose not to use them from cases where the user did not have the option to choose directed identifiers at all. In both cases, the data shared back via the browser isn’t verifiably directed and so the browser would require a RP tracking consent step for both.
   * From a UX perspective and ecosystem incentives perspective, we may want to differentiate the experience for each case.
   * This downside is not shared by pure policy based approaches or approaches with browser mediation, i.e., [3].
 * Revealing the RP to the IDP becomes a problem if, in the future, privacy restrictions are added on things like referrer on full page navigation.
+* If permission prompts are too frequent, users may become trained to click through them without thinking (i.e. 'warning fatigue').
+
+## Mock
+
+![](static/mock19.svg)
 
 ## Other design options