Registering paying users for a web-app


#1

Usually, when I go to some sort of web-application provider, I must create a login/account with them and register to user their paid services.

But with Solid we expect users to authenticate with thier WebId, meaning users already have an account elsewhere - do we then want them to create yet another account for the specific web-application? Potentially meaning they need to login twice to access the service?

It seems to me that there should be an easy-to-use standard Solid way of linking accounts, such that the web-app service provider can detect a new login from a WebId, inform the user immediately that they are newcomers to the service and would they, please, fill-out the payment details (or select the free plan), fetch as much information as possible from the WebId profile, and then automatically link the WebId account with their own automatically generated account.

Maybe this is all well-known, but perhaps it was worth having this kind of workflow well defined in the Solid “best practice” documentation.


#2

This raises another question - in order to allow the web-app’s server to link the WebId with some internal account, the web-app/browser must be able to prove it’s WebId to the server.

Unfortunately the server was never involved in the login process which is strictly confined to the browser and the web-app’s javascript code, so the server has no knowledge of that process.

The web-app cannot simply POST it’s WebId to the server since anybody else would be able to do the same with any WebId they wanted.

Neither can the web-app build a signed OpenID Connect token to POST as the signing key would be available to anyone that can read the javascript code.

So how does the web-app / browser-javascript-code prove the WebId it received to the server it is served from? Is there any token of some sort the web-app can send to the server and allow it to validate it with the remove WebId identity provider?