Difference between revisions of "WebID"

From Bitnami MediaWiki
Jump to navigation Jump to search
(Created page with "== Overview == Google's WebID is designed to disintermediate publishers from their visitors.<ref>https://github.com/samuelgoto/WebID/blob/master/consumers.md#the-delegation-or...")
 
m
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 
== Overview ==
 
== Overview ==
Google's WebID is designed to disintermediate publishers from their visitors.<ref>https://github.com/samuelgoto/WebID/blob/master/consumers.md#the-delegation-oriented-variation</ref>  
+
Google's WebID is designed to disintermediate publishers from their visitors.<ref>https://github.com/samuelgoto/WebID/blob/master/consumers.md#the-delegation-oriented-variation</ref> Recently Google renamed this initiative to "FedCM," to represent Federated Credential Management.<ref>https://wicg.github.io/FedCM</ref>
  
 
WebID moves the sign-in (also called "authentication") process from the competitive market of authentication service providers into the web client browser. Authentication service providers are also called "Identity Providers (IDP)" or "issuers."
 
WebID moves the sign-in (also called "authentication") process from the competitive market of authentication service providers into the web client browser. Authentication service providers are also called "Identity Providers (IDP)" or "issuers."
Line 16: Line 16:
  
 
By disintermediating organizations from the people who choose to authenticate into their service, would likely lead to publishers only accepting authentication credentials known to be useful for proactively communicating with their registered users and validating specific information about them. Organizations might for example rely on a service that ensures the registered users do not engage in fraudulent activity with other organizations.  
 
By disintermediating organizations from the people who choose to authenticate into their service, would likely lead to publishers only accepting authentication credentials known to be useful for proactively communicating with their registered users and validating specific information about them. Organizations might for example rely on a service that ensures the registered users do not engage in fraudulent activity with other organizations.  
 +
 +
This effort seems targeted at hashed-email based solutions, such as [[UID2]].
  
 
== Regulator Perspectives ==
 
== Regulator Perspectives ==

Latest revision as of 00:00, 18 October 2021

Overview

Google's WebID is designed to disintermediate publishers from their visitors.[1] Recently Google renamed this initiative to "FedCM," to represent Federated Credential Management.[2]

WebID moves the sign-in (also called "authentication") process from the competitive market of authentication service providers into the web client browser. Authentication service providers are also called "Identity Providers (IDP)" or "issuers."

Google suggests that when people authenticate into web properties they primarily want to do so anonymously.[3]

Google has proposed three variants of WebID:

  1. Permission prompt. Web client presents warnings associated with organization's request for the user to sign-in.
  2. Mediation. Consent prompts are bundled with the user's initial action to request to sign-in, such as always declaring their offline identity. Under the WebID mediation model, Google states that its web client will control all defaults.[4]
  3. Delegation. Under this model the authentication service provider is unaware of which service a user is authenticating into.[5]

Impact

Google recognizes that many websites require authentication (e.g., email service providers, subscription, purchase and registration). However, adding popup warnings for actions that clearly require user input and choice adds additional friction to the user experience.

By disintermediating organizations from the people who choose to authenticate into their service, would likely lead to publishers only accepting authentication credentials known to be useful for proactively communicating with their registered users and validating specific information about them. Organizations might for example rely on a service that ensures the registered users do not engage in fraudulent activity with other organizations.

This effort seems targeted at hashed-email based solutions, such as UID2.

Regulator Perspectives

The UK CMA noted (5.26,5.47,5.78) that should Google impair the user experience provided by rivals, "Chrome would have access to all the user’s log in data, which it could choose to share with Google’s advertising services after the introduction of the proposals." This concern is substantiated by Chrome already sending a browser identifier called "X-Client Data" exclusively to Google controlled web properties.

The UK also noted by moving authentication into the browser, "the browser adds more friction (eg in the form of permission prompts) or takes control of choice architecture around the use of federated log-in."

The UK CMA noted Google's proposal would:

  1. "lead to Google’s rival publishers offering a worse service to both users and advertisers when competing with Google to attract advertiser spend to their ad inventory,"
  2. "add friction to the user experience and lead to user frustration, reducing user visits,"
  3. "lead to the disintermediation of publishers with harmful consequences for their ability to track users on their properties."[6]

Note: Google has made no commitment that it will apply WebID for managing the authentication on its own web properties and services.

Open Questions

  • Will Google allow people to opt out of Google's WebID notifications?
  • What terms and conditions will Google's WebID offer to people?

References