Difference between revisions of "WebID Comparison"

Latest revision as of 11:56, 18 October 2020

Full Title

Comparison between various proposals for Web ID.

Goals

• Give the user agent the information needed to help the user decide if they want to proceed to identify themselves to a web site.
• Don't keep pestering the user for information that they have already volunteered.

Context

Several proposals exist starting from Tim Berners-Lee in 2020-03-05 to rescent version from the browser folk and the decerntalized ID folk, all in the W3.

WebID 1.0

• The first proposal from Sambra, Story and Berners-Lee sought to deal with a distributed Social Web.
• A WebID is an HTTP URI which refers to an Agent (Person, Organization, Group, Device, etc.). A description of the WebID can be found in the Profile Document.
• A WebID Profile Document is a Web resource that MUST be available as text/turtle [link broken], but MAY be available in other RDF formats.
• WebIDs can be used to build a Web of trust using vocabularies such as FOAF [FOAF] by allowing people to link together their profiles in a public or protected manner.
• URI fragments (#me) support sub sets or offshoots of the profile doc which is available at the base URI.
• Supported several authentication schemes like WebID-OIDC Authentication Spec for decentralized systems.

W3C-CCG+DIF Web ID

• W3C Credentials Community Group (CCG) and Decentralized Identity Foundation (DIF) have both created lightweight ways of bootstrapping webstandards to prove that a web domain and a DID (rotatable, cryptographic identifier) are controlled by the same party
• Normally, DIDs are published and their control proven through a DID "method" (system-specific driver) and "resolver" (application). Using these two specifications (or a combination of both), DID "Document" (resource) information is instead delivered directly from the web domain, making its contents essentially self-attested unless corroborating publication can be checked out of band.
• Well Known DID Configuration is a DIF working group specification (not currently standards-track) used mostly for proofs-of-concept or research implementations that describes the following well-known endpoints. These all are directed at sites that are DID-enabled rather than at sites that have multiple sources of Authentication. There appears to be no plan to enable discovery of a DID method from a general purpose app like a web browser; there are, however, publication/discovery methods that utilize blockchains (particularly Ethereum; see, for example, Ceramic, 3Box, etc), the presentation-exchange/credential-manifest specifications (also DIF work items), and in Hyperledger Aries. These are mostly for discovering "public DIDs" (institutional and/or issuance identities) rather than individual IDs, so the analogy to WebID breaks down a bit.
  • Well Known DID Configuration https://example.com/.well-known/did-configuration.json. returns a valid JSON object containing Domain Linkage Credentials, which contain cryptographically verifiable claims that prove the same entity controls both the included DIDs and the origin the resource is located under.
• DID:Web is a CCG work item that formalizes the earlier .wellknown work a bit and extends it to different kinds of DID Methods and context. For more info, see spec author Dmitri Zangadulin's slide deck from Q1 2020.
• Editor's note: One major factor in integrated W3C DIDs with other standards is the divergence between LD JSON and non-LD JSON handling and encoding. Defining protocols and providing implementation guidance accordingly is still an ongoing process which hinders simple interop between production implementations and major experiments in the space, and thus adoption or integration with other related standards.

WICG Web ID

• The goal of the Web ID was to enable a good Authentication user experience while still enforcing bans on third party tracking, which is indistinguishable from OIDC.
• 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.
• A piece of json-LD is presented as a fixed file containing (at least) a type filed and a set of policies. There is currently no requirement to actually send an "id" field.
• The policies that can be returned are theoretically unlimited. Only privacy policies are enumerated.

Attempt at synthesis

• See the Web ID page in this wiki for current status.
• It has been suggested that the WICG web ID be modified to always contain an ID field and to be specified for more types that just the "identifier provider".
• The policies can be expanded to include authentication methods supported.
• None of the above address the user experience. It is expected that users would not be bombarded with duplicate requests for information.

Alternate Approaches

Trust Token

• The Trust Token explainer from the blink (browser engine) team.
• a new API for propagating a notion of user authenticity across sites, without using cross-site persistent identifiers like third party cookies. Trust Token is built on Privacy Pass for anonymous tokens that can't be tracked between issuance and redemption.
• Privacy Pass issues cryptographically blinded tokens to the browser to be sent to other web sites. They are redeemed automatically when a future challenge page is seen.

References