Initiating User Registration via OpenID Connect

[jaxoncreed]

We might want to consider integrating this draft recommendation in the solid auth spec: https://openid.net/specs/openid-connect-prompt-create-1_0.html as it would be especially useful for Solid.

Traditional OIDC presupposes that a user is already registered with an IDP before the login process begins. However, with solid, a user might want to use a solid-compatible application without ever having registered with a solid-compatible IDP.

It would be useful to allow app developers to provide a "register" button that initiates the login process beginning with a registration flow rather than a login flow.

[acoburn]

Just want to note here that this could be an interesting optional feature. Requiring support, however, would be hugely problematic for anyone implementing an identity broker, which is important for integrating Solid with OAuth2, SAML or traditional OIDC environments -- or, in fact, with any IdP that doesn't currently support Solid

[elf-pavlik]

I think this shares some issues with solid/authentication-panel#5 and also tries to deal with User Lifecycle. I see IdP as much higher priority role (especially if it hosts WebID) than any single client application. For that reason I would really hesitate to encourage applications to suggest specific IdP to the user. How about we try to explore those on boarding scenario in https://github.com/solid/user-lifecycle-panel and bring back some specific authN related requirements afterwards?

In general application should have less expectations on longevity, IdP should ensure certain longevity especially if they host user's WebID.

[michielbdejong]

I think even if the IDP honours this request to prompt-to-create, it will still have a "or do you already have an account?" button or link. And even if the IDP does not understand this optional request to prompt-to-create, its default login screen will still have a "or register here" button or link. So yes, useful feature, And yes, also degrades very gracefully if it's optional.

[michielbdejong]

See also gitter discussion at https://gitter.im/solid/app-development?at=5f77ac77f9cfbe19f935cf10

[woutermont]

I'm picking up this thread in light of the linked issue.

While I get the reactions that this is an unnecessary or at most optional feature, the recurring issues stuck on this seem to indicate it would be worthwhile to brainstorm a bit further about standardizing this:

• https://github.com/solid/solid-auth-client/issues/102 of Inrupt's client library is blocked exactly because of the lack of a standard for user registration.
• As @RubenVerborgh pointed out in https://github.com/solid/solid-spec/issues/138, at least some account management standards are needed in the specification so that "different apps can manage accounts from different servers". The emphasis there should be on "different": if we want apps to be independent of Identity Providers, the apps should be able to rely on the specification, also in use-cases where their users does not yet have an account.
• The use-cases I mention in https://github.com/solid/solid-oidc/issues/46 show that even adding or changing identification claims at one's Identity Provider should preferably be standardized in some way.
• Even the gitter communication you linked to, @michielbdejong, actually shows that there is indeed a step missing (viz. being redirected after registration) to provide the same UX with the currently possible flows.

So let's think about this some more 🤔

[acoburn]

Is there anything stopping an identity provider from implementing the openid-connect-prompt-create draft today? I certainly don't see any reason that an IdP couldn't. Of course many IdPs will choose not to (e.g., a system where identity is managed by an underlying ActiveDirectory authority) or may have their own implementation-defined way to do this (i.e., nearly everywhere else).

Given that the proposed mechanism is still in draft form, and it is unclear whether it will ultimately be adopted by the OpenID community, I suspect that we need a lot more implementation experience before making any recommendations. @woutermont are you planning to implement this? Is anyone planning to implement this?

[woutermont]

Of course, current classic OIDC providers could perfectly implement the create prompt, but have not (yet).

I fail to see, however, how that prevents Solid-OIDC from adopting it. After all, the current draft is already so complex that it is impossible to make most popular OIDC providers compliant without some serious backend development:

• Some providers don't support DPoP (which is also still a draft btw).
• A number of clients do not allow to customize the OIDC Discovery document with a solid support claim.
• No provider currently supports checking ClientID documents.

Yet in none of these cases, such lack of current support has prevented Solid-OIDC from making it mandatory.

Moreover, we are indeed actively trying to implement this functionality in client projects and our own products! That is exactly why I am asking the panel and community to keep brainstorming about this. The solution does not have to be a create prompt, but the demand is definitely there.

[acoburn]

After all, the current draft is already so complex that it is impossible to make most popular OIDC providers compliant without some serious backend development

By that argument, adding another requirement to this specification makes very little sense.

No provider currently supports checking ClientID documents

I can think of two that currently support this.

[woutermont]

No provider currently supports checking ClientID documents

I can think of two that currently support this.

Which ones? I'm talking about classic OIDC providers, of course, not ones that were built specifically for the Solid ecosystem. Your point, after all, seems to be that we should not require something that existing providers do not eagerly want to implement.

After all, the current draft is already so complex that it is impossible to make most popular OIDC providers compliant without some serious backend development

By that argument, adding another requirement to this specification makes very little sense.

No, by that argument, either the spec has already to much requirements for existing providers to adopt (in which case we should make it simpler), or your point does not really hold (in which case it won't hurt adding extra requirements for user registration).

[acoburn]

ClientIDs are defined specifically for Solid-OIDC. A server that doesn't implement Solid-OIDC would not, ipso facto, implement a Solid-OIDC specific feature.

I am very wary of adding additional requirements to Solid-OIDC. Especially requirements that have not been proven to be absolutely essential. Please first implement this feature yourself and provide implementation experience. Once we have that, I would be happy to consider it. Absent any implementation experience, I have a hard time understanding why we would mandate all implementations to support this, especially since there are clear cases where this feature is either irrelevant or problematic.

[acoburn]

The Solid-OIDC draft currently adds four requirements above vanilla OIDC:

• webid claim -- this is specific to the Solid ecosystem. Without it, Solid apps and servers do not have a dereferencable URL to rely on. This is required for the basic operation of Solid
• DPoP support -- this is a feature that addresses security issues that are particular (but not limited) to the decentralized nature of Solid. Without this, the security of Solid would be compromised
• Client Identifier support -- this is also a feature that addresses security issues that are particular to an open Solid ecosystem. Without this, the security of Solid would be compromised (in a different way than what DPoP addresses)
• Discovery -- a client needs a mechanism to know whether the IdP supports the above requirements

There is discussion about whether the webid claim can be tied to a particular scope (e.g. a webid scope). With that change, which I anticipate will be made, it would be possible to re-use the existing scopes_supported mechanism in OpenID connect, making the fourth ("Discovery") requirement part of regular OpenID Connect. That is, there would be no need for a special solid_oidc_supported field in the well-known document.

The thing that these requirements have in common is that they are absolutely necessary for Solid. They are not "nice to have" or "useful features". All such non-essential features are things that any implementation can support, if so desired, but making them a required part of a specification raises the bar on all implementations.

[woutermont]

ClientIDs are defined specifically for Solid-OIDC. A server that doesn't implement Solid-OIDC would not, ipso facto, implement a Solid-OIDC specific feature.

Aiming for a growing Solid ecosystem, I would expect that we hope for existing OIDC providers to extend their frameworks to incorporate Solid-OIDC-specific requirements, instead of trying to get everyone to start using new, unknown providers.

Please first implement this feature yourself and provide implementation experience.

This is exactly what we will do. We just don't want to pick any of X possible implementations based on just our own insights and use-cases, but rather brainstorm and get feedback from the community about how we best approach such a first implementation.

[acoburn]

Please first implement this feature yourself and provide implementation experience.

This is exactly what we will do.

Excellent. We will be interested in learning about your implementation experience.

[dkdndes]

A new standard is currently in the doing, please check open-id-connect-connect-prompt-create.