Flow to confirm WebId Ownership
See original GitHub issueWhen a user signs up with an external WebId via the default Email-Password interaction, they should be asked to place a verification triple in their WebId so it is not possible to squat on WebIds.
- Upon sign up, a verification token is generated and saved in the IdP’s database
- A UI is rendered that tells the user how to put their verification token in their WebId and how to put the
solid:oidcIssuer
predicate in their WebId. - After pressing submit on that UI the server checks to see if the WebId has both the verification triple and the
solid:oidcProvider
triple - If the WebId does not, it returns the same instructions with an error message
- If the WebId does, it creates an account and continues with the login flow as normal.
Issue Analytics
- State:
- Created 3 years ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
Proving Ownership of a Flow Account - Flow Developers
Proving ownership of an on-chain account is a way to authenticate a user with an application backend. Fortunately, FCL provides a way to ......
Read more >Change the owner of a cloud flow in Power Automate
Learn how to change the owner of a solution-aware cloud flow in Power Automate. ... Screenshot that shows confirmation for the owner change....
Read more >Solid-OIDC Primer - Solid project
This primer is designed to provide the reader with the basic knowledge required to understand Solid OpenID Connect authentication flows.
Read more >SharePoint Online: Get Site Collection ID (or Web ID) using ...
To Get Site Collection ID, hit this URL in the browser: https://<tenant>.sharepoint.com/sites/<site-url>/_api/site/id; To get the subsite ID (or ...
Read more >Classic OIDC vs Solid OIDC - Documentation - Digita
We will demonstrate the differences between the classic OIDC flow and the Solid OIDC ... containing Claims that prove the identity of the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I’m glad it helps 😃
It is meant to be the default mechanism.
I’m not too sure what the use case for adding a version of the “enabling IdP protocol” where the IdP relies on another IdP to do so, but without having given it much thought myself, I think you could make a secure one if you wanted to. But you would still need to edit the WebID by adding the new issuer in any case before you can use your newly enabled IdP.
Mmm… if you’re registering with an external WebID, you’d expect to have the WebID setup, no?
So the use case we’re trying to cater for here is actually the more generic:
OK. fair enough.
I’m arguing that we don’t need any randomly generated token.
Assuming that
https://example.org/people#alice
registers forhttps://alicepod.other.example/
, then I suggest Alice adds something like:Why would this need to be a token?
Or why not even
solid:oidcIssuer
?