articleBody
| -
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.
-
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?
|