Proposal: Rename WebID-OIDC spec to Solid-OIDC about authentication-panel HOT 20 CLOSED

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

from authentication-panel.

+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.

from authentication-panel.

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.

from authentication-panel.

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.

from authentication-panel.

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.)

from authentication-panel.

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.)

from authentication-panel.

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

from authentication-panel.

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.

from authentication-panel.

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.

from authentication-panel.

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.

from authentication-panel.

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? :-) ).

from authentication-panel.

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

from authentication-panel.

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

from authentication-panel.

No objections from me to Multi-RS OIDC.

from authentication-panel.

As discussed on today's call the id_token only serves purpose of authenticating the user with the Client, doesn't really get used with any of the Resource Servers #27 (comment)

When it comes to access_token(s) presented by Client to Resource Servers (other than OIDC Provider user info endpoint). The token will allow RS to know which User delegated access to the Client (eg. sub in JWT), but OIDC doesn't really cover that authorization part. In the end we may have in a way indirect authentication to RS through the access token used for authorization.

I think we should first clearly define which existing specifications do we use, how we combine them and what new we need to add. Once we agree on how things will work we will have better ground for naming it accordingly.

from authentication-panel.

an access token issued to the client by the OIDC Provider, in normal OIDC/OAuth2, is opaque and doesn't necessarily have any structure (that is the case in almost all examples in specs, and is the case in my own implementation). requiring it to have some structure (say, a JWT with some well-known claims) does two things:

1. forces a current OIDC Provider to make potentially large and non-optimal implementation changes to give these tokens an externally-inspectable form;
2. substantially turns the access token into an identity token.

additionally, the access token (unless it can be guaranteed that it was bound to a confirmation key) gives its bearer access to protected resources at least at the OP (the userinfo endpoint) and potentially other protected resources (for the general OAuth2 case).

requiring changes to the structure of an access token is a much bigger ask (and bigger risk to adoption and interop with exising OIDC implementations) than adding additional claims to an identity token.

from authentication-panel.

To avoid moving away from just the naming issue, I've responded to id_token usage in #27 (comment)

from authentication-panel.

I don't think the rename issue depends on structure of access_token, thanks for moving the discussion to #27.

from authentication-panel.

Latest draft mandates 'aud' claim in JWT access token to have constant value of solid. To have it not coupled with solid we may need to adjust it to some more general value eg. web, or multi-rs. It doesn't matter as long as solid storage implementations acting as RS expect this value.

from authentication-panel.

Given that the current draft of the Solid OpenID Connect authentication protocol is named Solid-OIDC, I am marking this as resolved.

from authentication-panel.