Difference between revisions of "Web ID"
From MgmtWiki
(→Problems) |
(→Solutions) |
||
| Line 15: | Line 15: | ||
* The path to a solution started on [https://github.com/WICG/WebID/blob/master/design.md GitHub Early Explorations] | * The path to a solution started on [https://github.com/WICG/WebID/blob/master/design.md GitHub Early Explorations] | ||
* Ii\t is clear that there are relatively few public IDPs in use (say, tens), particularly in comparison to the number of RPs (say, millions) and their users (say, billions). A structural change that only requires adoption by IDPs and no changes or engagement on the part of RPs and users is significantly easier compared to redeploying millions of RPs or retraining billions of users. | * Ii\t is clear that there are relatively few public IDPs in use (say, tens), particularly in comparison to the number of RPs (say, millions) and their users (say, billions). A structural change that only requires adoption by IDPs and no changes or engagement on the part of RPs and users is significantly easier compared to redeploying millions of RPs or retraining billions of users. | ||
| + | ===Principles=== | ||
| + | # Least Disclosure: The data exchange should disclose as little as possible for a use that is as constrained as possible, incrementally increasing the scope of disclosure with additional explicit consent when that's relevant contextually. For example, unbundling overly broad scopes (e.g. unbundling authentication from authorization) into multiple granular steps that are asked independently and incrementally. | ||
| + | # Least Surprise: the data exchange should never have consequences that exceeds the level of consent and user understanding (including second-order consequences). For example, enforcing the use of directed profiles for the majority of the cases prevents unnecessary release of correlation handles. | ||
| + | # Path Dependence: the set of design options we have is limited by the decisions that have been made in up to this point, regardless of whether they are relevant or not. For example, it seems clear that breaking Server-Side Backwards Compatibility increases the deployment window exponentially and proportionally to the number of relying parties. | ||
| + | |||
| + | ===High Level Identification API=== | ||
==References== | ==References== | ||
[[Category: Identifier]] | [[Category: Identifier]] | ||
Revision as of 11:34, 11 September 2020
Contents
Full Title or Meme
The Web ID is designed by Google to give users an identifier that can be authenticated on their phone and used anywhere.
Context
- Web ID Explainer
- Web ID GitHub repository part of W3C Web Platform Incubation Community Group
- Most of Relying Parties (RPs) use one button per IdP on a web site that takes the user to an IdP sign-in experience.
- It has been proposed in OIDC#Section_7 to enable URL links in the user's browser to enable self-issued identifiers with the URL "OPENID://".
Problems
- The common way for a user identification to be enabled on a web page with OIDC. This method works well, but is indistinguishable from tracking of user's across the web, which is something that Privacy experts have been trying to block.
- Millions of RPs and Billions of Users indicate that fast deployment of a new method will need to leverage both the deployed RPs and a User Experience (UX) that matches user expectations.
Solutions
- The path to a solution started on GitHub Early Explorations
- Ii\t is clear that there are relatively few public IDPs in use (say, tens), particularly in comparison to the number of RPs (say, millions) and their users (say, billions). A structural change that only requires adoption by IDPs and no changes or engagement on the part of RPs and users is significantly easier compared to redeploying millions of RPs or retraining billions of users.
Principles
- Least Disclosure: The data exchange should disclose as little as possible for a use that is as constrained as possible, incrementally increasing the scope of disclosure with additional explicit consent when that's relevant contextually. For example, unbundling overly broad scopes (e.g. unbundling authentication from authorization) into multiple granular steps that are asked independently and incrementally.
- Least Surprise: the data exchange should never have consequences that exceeds the level of consent and user understanding (including second-order consequences). For example, enforcing the use of directed profiles for the majority of the cases prevents unnecessary release of correlation handles.
- Path Dependence: the set of design options we have is limited by the decisions that have been made in up to this point, regardless of whether they are relevant or not. For example, it seems clear that breaking Server-Side Backwards Compatibility increases the deployment window exponentially and proportionally to the number of relying parties.
