WebID Comparison - Revision history

Tom: /* Context */

2020-10-18T19:56:14Z

‎Context

By caballero: Updating DIF/CCG section to be a bit more precise, and added an explanatory link.

2020-10-05T17:53:59Z

Updating DIF/CCG section to be a bit more precise, and added an explanatory link.

Tom: /* WICG Web ID */

2020-09-23T15:48:56Z

‎WICG Web ID

Tom: /* Attempt at synthesis */

2020-09-23T15:46:42Z

‎Attempt at synthesis

Tom: /* Goals */

2020-09-23T03:35:45Z

‎Goals

Tom: /* Attempt at synthesis */

2020-09-23T03:35:09Z

‎Attempt at synthesis

Tom: /* Full Title */

2020-09-23T03:34:03Z

‎Full Title

Tom: /* Attempt at synthesis */

2020-09-23T03:30:42Z

‎Attempt at synthesis

Tom: /* WICG Web ID */

2020-09-23T03:30:01Z

‎WICG Web ID

Tom: /* Trust Token */

2020-09-23T03:28:24Z

‎Trust Token

@@ Line 7: / Line 7: @@
 ==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.
+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 [https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html first proposal] from Sambra, Story and Berners-Lee sought to deal with a distributed Social Web.

@@ Line 16: / Line 16: @@
 * Supported several authentication schemes like [https://github.com/solid/webid-oidc-spec WebID-OIDC Authentication Spec] for decentralized systems.
-==DIF Web ID==
+==W3C-CCG+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.
+* W3C Credentials Community Group ([https://w3c-ccg.github.io/ CCG]) and Decentralized Identity Foundation ([https://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
-* [https://identity.foundation/.well-known/resources/did-configuration/  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.
+* 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  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.
+* [https://w3c-ccg.github.io/did-method-web/ 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 [https://docs.google.com/presentation/d/1bxt1F4RN9mb3ErLatA4MViW5qeDyuZQlhEPaPIVmIio/edit#slide=id.g7dedce0bc2_0_31 slide deck] from Q1 2020.
 ==WICG Web ID==

@@ Line 23: / Line 23: @@
 ==WICG Web ID==
 * [https://github.com/WICG/WebID Web ID Explainer] which describes (1) the classification problem, (2) the RP tracking problem and (3) the IdP track problem.
 * [https://github.com/WICG/WebID Web ID GitHub repository] part of W3C Web Platform Incubation Community Group

@@ Line 33: / Line 33: @@
 ==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".
+* 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.

@@ Line 4: / Line 4: @@
 ===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.
 ==Context==

@@ Line 1: / Line 1: @@
 ==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.

@@ Line 24: / Line 24: @@
 * 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.
 ==Attempt at synthesis==

@@ Line 29: / Line 29: @@
 * 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".
-==Trust Token==
+==Alternate Approaches==
 * The [https://groups.google.com/a/chromium.org/g/blink-dev/c/UIvia1WwIhk/m/DuXLKdF7AgAJ?pli=1 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.