Difference between revisions of "Web ID"
From MgmtWiki
(→High Level Identification API) |
(→High Level Identification API) |
||
| Line 21: | Line 21: | ||
===High Level Identification API=== | ===High Level Identification API=== | ||
| − | # The browser | + | # The browser sends a header value that can be interpreted by "woke" RPs |
| − | # User Intent is indicated by a gesture, such as a button click where the button has a clear meaning, like '''Personal''' | + | # User Intent is indicated by a gesture, such as a button click where the button has a clear meaning, like '''Personal''' in "woke" RPs UI. |
# The browser evaluates the environment, for example: | # The browser evaluates the environment, for example: | ||
| − | ## Does the web site have a recognizable Identifier? --> this is a new concept introduced with this API (e.g. vid = verifiable ID and a signature to prove it | + | ## Does the web site have a recognizable Identifier? --> this is a new concept introduced with this API (e.g. vid = verifiable ID and a signature to prove it; may require round trip) |
## Is the Identifier in a list of enterprises that the user has already established trust? --> If yes, just go through local user authentication steps. | ## Is the Identifier in a list of enterprises that the user has already established trust? --> If yes, just go through local user authentication steps. | ||
## At this point the user may be presented by choices on which IdP to use, which can include a native app running on the browser. The RP will help with this decision. | ## At this point the user may be presented by choices on which IdP to use, which can include a native app running on the browser. The RP will help with this decision. | ||
### Note that a legacy RP that is note "woke" can just use an existing api. If the IdP is registered with the browser, the new experience can still be invoked. | ### Note that a legacy RP that is note "woke" can just use an existing api. If the IdP is registered with the browser, the new experience can still be invoked. | ||
| − | ### If neither the RP | + | ### If neither the RP nor the IdP is "woke" the experience will not change from before. Eventually this method will be deprecated by new versions of the browser. |
==References== | ==References== | ||
[[Category: Identifier]] | [[Category: Identifier]] | ||
Revision as of 11:55, 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.
High Level Identification API
- The browser sends a header value that can be interpreted by "woke" RPs
- User Intent is indicated by a gesture, such as a button click where the button has a clear meaning, like Personal in "woke" RPs UI.
- The browser evaluates the environment, for example:
- Does the web site have a recognizable Identifier? --> this is a new concept introduced with this API (e.g. vid = verifiable ID and a signature to prove it; may require round trip)
- Is the Identifier in a list of enterprises that the user has already established trust? --> If yes, just go through local user authentication steps.
- At this point the user may be presented by choices on which IdP to use, which can include a native app running on the browser. The RP will help with this decision.
- Note that a legacy RP that is note "woke" can just use an existing api. If the IdP is registered with the browser, the new experience can still be invoked.
- If neither the RP nor the IdP is "woke" the experience will not change from before. Eventually this method will be deprecated by new versions of the browser.
