Difference between revisions of "Web ID"

Revision as of 11:51, 1 August 2021

Full Title or Meme

The Web ID is designed by Google to give users a web site 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://".
• The context in most web browsers is just the DNS domain. This does not correspond well to the real-world. It is not clear if the user context can be represented in any way.

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.
• Web sites may need to have different legal IDs, for example amazon.com, Amazon.ca and amazon.co.uk. These should be able to share a common logon and perhaps policies.
• Different legal jurisdictions may have different policies to accommodate different legal systems. The user's don't care, they just want to get their work done.
• There are many ways to aggregate web domain names to a single web ID, for example multiple locations or trust frameworks.

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" and optionally the method used to send a request for a native app to authenticate the user. The default method will be to redirect to "opened://".

Local Store

There will be a store of the sites that have established an authenticated binding to the user. This may be combined with existing stores and may be remotable at the developers discretion. The store will contain at a minimum:

1. WebID = a URN which is ideally supplied by the site. If not it will be the core part of the sites URL.
2. Date last used = Unix epoch date
3. Status = enum list that will contain active and blocked.
4. SUB = User's Identifier to be used with this site.
5. public key may be included by reference of the identifier.

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 webID = "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.
2. Add a Personal button on the registration page that will allow the user to make the choice (The sites acceptable to the RP can be "hidden" in the HTML for display by the browser to the user based on user agent settings.

User Intent

Besides the setting the "Personal" option in the browser settings, the user must perform some gesture on a page to initiate the process.

Authorization

One proposal is add an API to carry the user intent of the sort:

navigator.credentials.requestPermission({
 scope: "https://idp.com/auth/calendar.readonly",
 provider: "https://idp.com",
});

User Notifications

• It is necessary for compliance of several governmental regulations for any web site to notify the user of several event types.
• The use of pairwise, or directed email address would be a privacy preserving technique that is recommended.

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.
5. A interesting property of the Personas protocol is that it made IDPs sign a certificate delegating the issuing/minting of JWTs to the Browser. It accomplished that by making the browser generate a public/private key pair () and have the IDP sign a certificate attesting that the browser's private key could issue certificates for a certain JWT.

References

• GitHub WICG WebID with issues and all that.
• presentation to blinkON 2020-11-18)