Web ID

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 which describes (1) the classification problem, (2) the RP tracking problem and (3) the IdP track problem.
• 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.
• In view of the changes to the way that identifiers are issued by the user rather than by some central authority, simply fixing the existing paradigm is insufficient. What we need is a paradigm shift to a better world where the user has more control.

Solutions

• The path to a solution started on GitHub Early Explorations Which addresses Classification and IdP tracking, but does not address RP Identification or tracking directly. This proposal differs in two ways from that proposal:

1. It addresses the user self-operated IdP and Identifier creation where the external IdP is replaced with verifiable credentials.
2. It addresses the RP Identifier and policy issues. Here the webid element is required at the RP site as well as at other providers of credentials.

• It 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

1. User is in Control: the entire proposal should start with the user experience to be sure that the user is able to understand the options so that the user can make good choices.
2. 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.
3. 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.
4. 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.

The WebID

The following piece of jsonLD id proposed for identifying and web site, RP or IdP.

// Available on a .well-known/webid file:
{
  "@context": "https://www.w3.org/ns/webid",
  "@type": "IdentifierProvider",
  "id": "did:example:123",
  "policies": [
    "https://tbd.org/policies/privacy/1.0"
  ]
  ... TBD ...
  // possibly signed by a neutral authority that verifies the claims?
}

High Level Identification API

1. The browser sends a header value that can be interpreted by "woke" RPs
2. 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.
3. The browser evaluates the environment, for example:
   1. 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)
   2. Is the Identifier in a list of enterprises that the user has already established trust? --> If yes, just go through local user authentication steps.
   3. 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.
      1. Note that a legacy RP that is not "woke" can just use an existing api. If the IdP is registered with the browser, the new experience can still be invoked.
      2. 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.
4. Browser queries IdP, which may be on the device
5. Browser asks user for consent to release data.
6. If user consents the browser sends the ID token to the RP.

Browser Assertion

Add new HTTP header Personal, or in the interim x-Personal that will indicate both the capability of the browser and the intentions of the user to engage in the new protocol. This will take the place of an "key" that has to be set in some strange with a browser setting. The value of the personal tag will just be the version number, to start with #0.1".

Changes to RP web page

There are several actions that web sites can take to be "woke" to allowing the user more control of their own identifiers.

1. Add the value vid = "URN" that identifies the real-world owner of the web site. It must be an identifiers known in the real-world, like a government, corporation or registered trademark.

User Intent

Besides the setting the "Private" the user must perform some gesture on a page to initiate the process.

Alternate Solutions

• Other solutions are, of course, possible some might include:

1. Automatically select client certificates for these sites. This would give a user a certificate for any site that the user registered for. Mutual Authentication could then be performed and both the user and site well satisfied of the other's identifier. Unfortunately we have some experience with EV Certs that is less than satisfactory.
2. A plugable USB (or NFC) device that contains user sign-in information.
3. Web Share is a proposed web API to enable a site to share data (text, URLs, images, etc) to an arbitrary destination of the user's choice. It could be a system service, a native app or another website. The goal is to enable web developers to build a generic "share" button that the user can click to trigger a system share dialog. See also: Specification, the formal draft spec. Native integration survey, for platform-specific matters.
4. App Links are HTTP URLs that bring users directly to specific content in your Android or iPhone app. They are, unfortunately, uni-directional so they cannot return data to the browser windows.