Clarify relationship to prior WebID work

[tomayac]

https://en.wikipedia.org/wiki/WebID

[samuelgoto]

Ah, good point. Yes, to the best of my understanding so far, entirely different projects in terms of motivations and technology choices.

Very unfortunate name collision, which we were planning to address once we know more what shape this takes.

For context, WebID's name inspiration/context come a lot more from OpenID ("OpenID built on the Web") and BrowserID (Mozilla Personas) than the WebID you are pointing to (which we only became aware much later in the process).

[rektide]

I spent a good 15 minutes trying to understand the relationship. W3C WebID is good technology, useful as heck. Used in Solid. In short, it's a way for users to have declared presence on the web. I kept looking for it's presence in this spec.

Current WebID draft.

[csarven]

WebID specifications: https://www.w3.org/2005/Incubator/webid/spec/

WebID Community Group: https://www.w3.org/community/webid/

We generally refer to WebID as an identifier (eg. HTTP URI) to denote an agent. WebID is central to authentication (eg. WebID-TLS, WebID/Solid-OIDC) and authorization (eg. Web Access Control / ACL).

WICG/WebID appears to share some problems, motivations, ... with the prior/ongoing WebID space but it may not be entirely aligned in terms of goals or technology choices.

The work using/extending WebID is also carried under the W3C Solid Community Group ( https://www.w3.org/community/solid/ ):

• Solid Ecosystem specification: https://github.com/solid/specification
• Authentication: https://github.com/solid/authentication-panel
• Authorization: https://github.com/solid/authorization-panel

I suggest that we identify areas where synergy may be possible.

[mfosterio]

@csarven These projects are more alike than you might originally think, when I originally listened to the W3C Breakout Talk I thought they were one in the same. Here is even an example of a WebID browser extension https://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_22/webid.html

This would be great.

The Solid Community has already taken off and some apps have been built on top of it. https://solidproject.org//apps

They are also seeing some good real world traction with NatWest Bank, the BBC, the government of the Belgian region of Flanders - and the NHS. https://www.bbc.com/news/technology-54871705

It is utilizing some common W3 standards and projects with Turtle, JSON-LD, RDF, OWL and can be queried with SPARQL they have even built a GraphQL query for developers that are familiar with these new trendy query languages https://gist.github.com/rubensworks/9d6eccce996317677d71944ed1087ea6

Here is the solid sever project built in node: https://github.com/solid/node-solid-server I would imagine you would be interested in this https://www.w3.org/2005/Incubator/webid/spec/tls/

They also hosted an Encryption at Rest talk at the WC3 TPAC break out session around https://github.com/decentralized-identity/confidential-storage https://youtu.be/DdnREB-oYr4

Here is an example query:
https://query.linkeddatafragments.org/#datasources=https%3A%2F%2Fruben.verborgh.org%2Fprofile%2F%23me&query=%7B%0A%20%20id%0A%20%20firstName%20lastName%0A%0A%7D&queryContext=%7B%0A%20%20%22%40context%22%3A%20%7B%0A%20%20%20%20%22foaf%22%3A%20%22http%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%22%2C%0A%20%20%20%20%22knows%22%3A%20%22foaf%3Aknows%22%2C%0A%20%20%20%20%22firstName%22%3A%20%22foaf%3AgivenName%22%2C%0A%20%20%20%20%22lastName%22%3A%20%22foaf%3AfamilyName%22%0A%20%20%7D%0A%7D&queryFormat=graphql

They have even built React Components https://github.com/solid/react-components and are branching off into other component libraries. It is the perfect Semantic Web Stack.

[BigBlueHat]

Very unfortunate name collision, which we were planning to address once we know more what shape this takes.

Please don't wait on renaming this project. Naming is hard and taking an existing name from an existing community doesn't win you any friends or collaborators.

At the very least, please hang a big sign on the repo that you are actively pursuing new naming and list the existing, deployed WebID work in the Prior Art section.

These name collisions (this isn't the first...) are easily avoidable with a bit of googling. 😉

Best of luck on making this a reality, regardless!
🎩

[samuelgoto]

Ok, here are a few options that occurred to us in case any of you feel inclined to vote. No promises on how we are going to use this data, but in case you want to cast a vote, here it goes: thumbs up/down the options below or comment with more options.

Full disclosure: figuring out the name of this API at this moment in time with the amount of information that we know feels extremely premature to me and falls really low on the list of problems I think about. But since this gets asked more often than I'd like, here it goes.

[samuelgoto]

WebSSO API

[samuelgoto]

Web Sign In API*

• There is a chance this is not an option because it is also already taken.

[samuelgoto]

Web Login API

[samuelgoto]

WebID Connect API

[samuelgoto]

Web FIM API

[samuelgoto]

Web Identity API

[samuelgoto]

Web Federation API

[samuelgoto]

Web Federation Credential Management API

[samuelgoto]

Federated Identity Management API

[samuelgoto]

Web Identification API

[samuelgoto]

Web Persona (as a tribute to mozilla persona -- not to be confused with Personas, the theme manager)

[samuelgoto]

Login Handler API (as an analogy to Payment Handler)

[samuelgoto]

Web Identifiers API

[samuelgoto]

(space 5)

[samuelgoto]

(space 6)

[samuelgoto]

Ok, feel free to suggest your own and have others upvote/downvote.

[majido]

Web Passport ?

[mknowles36]

Web Sign On / Web SignOn

[mknowles36]

Web Log On / Web LogOn

[dharanigo]

Web Access

[dmurph]

I think lean into the privacy part of it for users for the delegation part.

UntrackableUserId

This way we can ask the question of relying parties - "Are you going to support untrackable user ids?" Or another similar name that sounds good to users.

[samuelgoto]

Web Sign-in seems to be winning here. @stpeter tells me that that's being currently used by Mozilla, so I'm asking him if we can reuse first. If that doesn't work, Web Login seems to be the closet second.

Apologies for the delay here, naming is hard.

[alextcone]

I wonder if Apple would mind if you borrowed from the spirit of "Hide My Email" as it is very very close in nature to what is happening here. Something like Email Obfuscation API or even just Hide Email API?

[samuelgoto]

Possibly, but do not that it goes well beyond email. That is, the API is perfectly usable without any exchange of email addresses (obfuscated or not). So, I don't think we can tie it to "email" necessarily.

[kenrb]

Agreeing with @samuelgoto, the goal of this proposal is to allow identity federation to continue working in a private-by-default web but obfuscated identifiers are only one piece of that. Many use cases, especially when we look outside of consumer identity providers, are incompatible with 'Hide My Email'-like features but are still in the scope of what this project seeks to preserve.

[tantek]

@stpeter gave me a heads-up about this.

tl;dr: All the same reasons for not re-using WebID apply to Web Sign-in (and Sign-on is too similar), and thus we object to the proposed re-use.

There’s already an existing set of related specs[1][2][3], numerous deployed & in-use implementations[4][5], and an open standards community actively using (including numerous actual users using) the term / phrase / technology[6][7].

@BigBlueHat wrote in #41 (comment):
> Naming is hard and taking an existing name from an existing community doesn't win you any friends or collaborators.

Indeed.

To state it even more strongly, Google of all parties must not act in a bullying way (we must consider the outsized influence & power dynamics), even within the auspices / context of a CG (using a vote in a CG to justify squatting over an existing active spec and a community’s use thereof). Rallying more folks to tacitly or otherwise approve of bullying is still bullying, perhaps even a worse form of doing so.

I can sympathize with the naming challenges in the area of identity (seems fitting).

That noted, an exploration in a CG seems premature to worry so much about a "marketable" name, especially in an area where naming is hard.

Instead, make up a throwaway placeholder name (like WID2021), first get the technology right, working across at least a few different vendors relying/consuming each others identities interoperably, and then worry about an actual marketable name, perhaps at WD/CR time. We know this can work per the prior example of "Atom" which went through a few throwaway names like "Pie" before being standardized as Atom in RFC 4287 at IETF.

Thanks for your consideration,

Tantek

[1] https://microformats.org/wiki/web-sign-in
[2] https://microformats.org/wiki/RelMeAuth
[3] https://indieauth.spec.indieweb.org/ (previously a W3C Note published by the Social Web Working group: https://www.w3.org/TR/2018/NOTE-indieauth-20180123/)
[4] https://indieweb.org/Web_sign-in#Implementations
[5] https://indieweb.org/IndieAuth#Implementations
[6] https://indieweb.org/Web_sign-in
[7] https://indieweb.org/chat-names

(Originally published at: https://tantek.com/2021/238/t3/web-sign-in-existing-specs-users)

[csarven]

Checking in to understand the status of this issue. The issue was created one year ago - it'll be in exactly one week. Since then there's been an understanding that renaming is necessary and promises were made to follow through. But here we are.

---

What are WICG's next steps on this issue? @samuelgoto can you please finalise the renaming this week? Pinging WICG Chairs: @LJWatson @cwilso @yoavweiss @travisleithead , can you please follow through?

Is renaming in WICG's agenda? Is there an ACTION item with a due date assigned to someone? Are there minutes to past discussions on renaming? If this thread wasn't sufficient, would WICG recommend that it is added to the agenda of a relevant meeting so that people can show up and voice their concerns?

Both the Solid CG and the WebID CG (and I'd only presume some others) would like to request that the renaming process is finalised prior to upcoming TPAC 2021, and all significant references are updated e.g., TPAC session idea, this repo, and so on.

We'd like to request that a W3C Staff can follow through. @dontcallmedom , can you please help with this? Is there any mechanism in place to prevent naming collisions or name squatting in the future under the jurisdiction of W3C? After all, W3C did publish timetables for TPAC as well as allowing the organisation of the WebID event in irc.w3.org #webid.

---

How did we get here?

After initial activity here without a follow through, I have brought up this issue to the attention of TAG for general guidance: https://lists.w3.org/Archives/Public/www-tag/2020Oct/0000.html (in 2020-10). Understandably, there wasn't much TAG can do but they did acknowledge the concern (in 2021-04): w3ctag/design-reviews#622 (comment)

There has been at least one meeting in TPAC 2020 ( https://www.w3.org/2020/10/TPAC/breakout-schedule.html#webid ) that uses "WebID" - This issue itself predates that TPAC event.

I have brought up the naming collision casually in the TPAC 2020 meeting that took place in the "#webid" channel - the name that is actually reserved for the WebID CG by W3C. The quote below is not captured in the minutes ( https://www.w3.org/2020/10/29-webid-minutes.html ) but those with personal logs or W3C logs can surely verify:

csarven has to step away. Was hoping to bring up #41 (comment) at the end of the call :)

There was at least one joint session between the WICG and Solid CG to exchange notes where we also touched on the naming collision: https://github.com/solid/authentication-panel/blob/main/meetings/2021-02-22-webid.md (in 2021-02).

Still, there has been a yet another event using "WebID" proposed to the upcoming TPAC 2021: https://www.w3.org/wiki/TPAC/2021/SessionIdeas#WebID

Is @cbiesinger - the proposer of the event - unaware of all of this activity at this point? Was it approved by WICG?

---

Thanks for your consideration.

[samuelgoto]

Ah, apologies for the delay and thanks for the patience.

Internally (as well as in some places externally, like our spec draft) we started using the name Federated Credential Management API (largely as a result of the API being exposed as an extension of the Credential Management API and the extension of the existing FederatedCredential type) for the actual concrete proposal that we are pushing through.

That name (FCM) is starting to creep into our codebase and specs and so far seems to fit (there is no collision either because it extends the existing FederatedCredential type of the Credential Manager API -- it is also a bit ugly / precise, so not surprised that it doesn't have collisions).

That is, I think we should be ready to rename this before next week, unless anyone here objects.

What will be involved here will be:

• renaming this repo (WebID -> FCM (or some variation, like FederatedCredentialManagement or fedcreds or fed-cred-man or FedCM, etc))
• a global replace s/WebID/FCM/g (e.g. on this repo and on things like our entry on TPAC, etc)

I'm guessing that should work for you all, but just in the interest of being safe, I'll let this sit for a week or so before I pull the trigger.

Sincere apologies for the trouble, Sam

[stpeter]

Thanks for finding a name that doesn't collide with existing work.

[samuelgoto]

Ok, a week has gone by and nobody yelled (loudly [1]) at me so far.

I'm asking @cwilso to rename this repo from WebID to FedCM and I'll do a global r/WebID/FedCM/g later in a separate commit.

@cwilso can you help me rename this?

[1] some people seem to like FedID better than FedCM but I'm going to hold that for a possibly later rename if it ever comes up again. getting ourselves out of WebID right now is my priority.

[samuelgoto]

... and done!

Thanks @cwilso !

I'll take it from here and replace the names globally in our docs. I'll resolve this thread once we do.

Thanks all for the patience, and hope this diffuses the tension I (personally, unintentionally and unnecessarily) created.

[csarven]

That's great, thank you all!

Indeed naming is hard. We've all been there (and even on a daily basis) :)

Good luck with the FedCM work. Please close issue at your discretion.

[samuelgoto]

I'll take it from here and replace the names globally in our docs. I'll resolve this thread once we do.

Done.

I'm going to close this issue.

Feel free to re-open if:

• you run into the WebID string somewhere in our docs or
• you want to contest FedCM

[samuelgoto]

As a result of our deployment and implementation experience, I'm going to re-open this issue here because we learned a few things that are making us revisit how we name this API:

1. First, we are finding that it is going to be harder to deprecate the existing use of the existing FederatedCredential type that we are currently overloading. We knew that, by reusing it, we would have to make backwards compatible changes, but that's starting to create more trouble than we'd like and entirely deprecating its current deployment / adoption (which is extremely small, but not insignificant that is worth breaking it) is proving to be harder than we originally anticipated.
2. Second, as we ran origin trials, we learned from a variety of partners that there are two parts that are awkward: the term "federation" and the term "logging in". In many cases, largely based on OAuth, the users isn't "logging in" to the relying party, for example, while giving the user's information like their memberships, subscriptions, age verification or verified phone/emails without necessarily having an implication that the user is "logging in", so we are building variations of the UX where we use terms like "Use" or "Continue", in addition to, "Sign-in" and "Sign-up".
3. Third, we think we have a much better idea of how this API (and federation as a whole) relates to WebAuthn, specially as it starts being as recoverable and ubiquitous as federation.

So, our plan right now, is to move away from overloading the FederatedCredential interface and kicking off a new one (we considered a few alternatives: FederatedCredentialV2, MediatedFederatedCredential, VerifiableCredential, IssuedCredential, SocialCredential, etc. It is not ideal, but we are leaning towards IdentityCredential).

Of the most highly voted options / alternatives on this thread, two stand out:

• Web Identity API and
• Web Identification API

Both of them could work, and none of them seem to conflict with any prior art (I'm reaching out to @csarven over email/IM personally, but if one of these conflicts with any existing project you know, please do let me know).

We'll try to make a resolution on this before we send our intent-to-ship, so expect us to try to drive some resolution in the next weeks or so, but I just wanted to re-open this to be transparent about what we have learned from origin trials.

[dickhardt]

As a term of art, federation seems to be appropriately descriptive from how I understand the work --

there is little consensus on what identity is, and what it is not. I would imagine many people will view it as encompassing all identity -- which from the charter, is not in scope. :)

To continue the brainstorming on names:

Federation Mediation

is descriptive as the browser is mediating a federation protocol

[samuelgoto]

I'm going to re-open this issue here because we learned a few things that are making us revisit how we name this API:

I'm going to (re) close this thread here (to avoid overloading it) and open a new issue to to fork the conversation here as to how to proceed.

Here it goes: #331