Difference between revisions of "WebID Comparison"

Revision as of 19:30, 22 September 2020

Full Title

Comparison between various proposals for Web ID.

Context

Several proposals existing 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.

DIF Web ID

• Basically a correspondent is given by a DID which can be resolved into a DID document which is recovered from a public ledgier system.
• Well Known DID Configuration is a DIF working group document that describes the following well-known endpoints. These all are directed at sites that 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.
  • 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.
  • Other endpoints assume Linked-data, also know as json-ld which is currently under debate in the DID committee as other standards are focused on straight json, which would make interlop with existing systems very difficult.

WICG Web ID

• 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 suggest that the WICG web ID be modified to 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.

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