Proposal: Rename WebID-OIDC spec to Solid-OIDC

[dmitrizagidulin]

As we're starting to move towards an initial public draft of a 1.0 solid spec, now is the time to consider the naming of our authentication protocol.
This is a proposal to change the name of the authentication protocol (and the corresponding spec) to:

Solid-OIDC.

This would:

• Lay the groundwork for using DIDs in addition to WebIDs, in the future (as well as any other appropriate identifiers)
• Communicate that this is a Solid-specific variant of OpenID Connect 1.0 (which is, hopefully, as interoperable with OIDC 1.0 as possible).
• Differentiate the name of the authentication protocol from the existing WebID-OIDC (since there are likely to be breaking changes).

[justinwb]

+1 to renaming to ensure that we don't limit the scope (or the perception of the scope) to a very specific identity system. Another consideration is whether naming it Solid-OIDC limits the perception of its use only to the Solid ecosystem.

I think that using Solid as the prefix helps more than it hurts, because it focuses the efforts on the use case patterns that we need to solve in Solid. This narrows the scope of the problem space, and allows us to credibly explain why we aren't supporting certain features or capabilities that aren't relevant to our use cases. So for myself, I'm also +1 for Solid-OIDC.

[RubenVerborgh]

The original intention was to have orthogonal specs, such that the WebID-OIDC mechanism could be reused in contexts that are not Solid. Kind of how the Web specs are not Web-HTTP and Web-HTML but just HTTP and HTML.

Regarding:

Lay the groundwork for using DIDs in addition to WebIDs

I think we should just expand the scope of WebIDs to include non-HTTP URIs.

Solid-specific variant of OpenID Connect 1.0

I hope it won't be; it should be standard OpenID Connect extended with the fact that you can have an IRI as identifier.

[dmitrizagidulin]

I hope it won't be; it should be standard OpenID Connect extended with the fact that you can have an IRI as identifier.

I think absolutely everyone involved in the spec, from the editors, to Inrupt developers (especially @acoburn and team), to panel participants, are all aiming for maximum off-the-shelf compatibility with OpenID Connect.
However, given that Solid has several unique use cases and constraints on its authentication protocol, it is not possible to use standard OIDC - it will be a Solid variant, unfortunately.

[RubenVerborgh]

it will be a Solid variant, unfortunately.

Solid or WebID?

I would suggest to explicitly list those cases and constraints (likely as part of the spec document); one that I know of is that users are identified by a IRI. What are the others? (That will also determine the answer to the first question.)

[dmitrizagidulin]

Solid, specifically. We have constraint to support the Multiple Resource Server (multi-RS) use case (this is the "decentralized twitter" example), which requires authenticating to an arbitrary amount of resource servers who potentially have no prior relationship to an identity provider. (It requires the use an id credential (rather than an access token handed out by the IdP for a specific RS), combined with a Proof of Possession mechanism.)

[dmitrizagidulin]

And yes, those use cases and constraints will definitely be part of the spec document.

[RubenVerborgh]

Thanks, that's helpful. Still opposed to "Solid" in the protocol name; I believe we are addressing a problem (multi-RS) that is broader than Solid. I can't imagine the word "Solid" popping up in more than the title of the document.

I'd propose to have the list of cases / constraints before making the decision.

[dmitrizagidulin]

Np. We can hold off on the renaming until then.

[csarven]

The term "Web" in WebID covers all things.. on the Web =)

That for example includes aspects of DID that can be on the Web.

There is no need to rename. I would suggest to update the definition of WebID so that what is within the scope of WebID is more clear.

[TallTed]

I think we should just expand the scope of WebIDs to include non-HTTP URIs.

+1

WebID specs are all drafts (even though they say otherwise about themselves).

The (long stagnant) WebID CG can update them, and a WebID WG can be started to push them through RecTrack.

Join the WebID CG. Add some voice to the argument that "WebID" need not be limited to HTTP/S-scheme URIs, just as the Web is not actually limited to HTTP/S URIs, and away we go.

[kjetilk]

Could we condense the definition of WebID down to a bare essence?

I'm thinking about an WebID as a dereferencable URI identifying an agent that that agent can prove it controls... If we can get down to the essentials, it is easier to build orthogonal specs around it, and therefore to name things.

("agent that that agent", did you see that? Nice use of words, wasn't it? :-) ).

[jaxoncreed]

Perhaps "Multi-resource OIDC" is a good name because that's what we're trying to solve here.

[dmitrizagidulin]

+1 to Multi-Resource OIDC (or Multi-RS OIDC)!

[RubenVerborgh]

No objections from me to Multi-RS OIDC.