When using the login and handleRedirectAfterLogin functionality, as provided by the Inrupt libraries, as provided in the examples, this in essence seems to provide “full access” to a users POD. For example - when you login to a POD then it says it is using your “Web ID” - but this I think is really misleading. In fact, it is giving full access into your POD to do anything. (At least it seems that way to me)
I understand why this functionality is critical - you must be able to do this to control your POD when logged in as “you” - but this isn’t obvious.
Yes, this is confusing. If you could report it here, then Inrupt will know that people are running into this.
The second part of your post is about providing an identifier (“client application WebID”) for your app. This theoretically allows someone to specify access rules specific to your app. However, that option is still in flux and not supported by most servers yet, so I wouldn’t worry too much about it at this point in time.
@Vincent - This is the route that we want to go down however, and realise that this involves using the ESS edition, which I believe is currently running on Inrupt.com. However - without this it seems that you are either in essence
Opening up your entire POD to an application by signing in
Forcing an app to in essence “sign in” and you give permissions to that apps WebId prior to the initiation of request of information
I might have misunderstood however - so happy to be corrected! However - there doesn’t seem to be any subsequent requests for “X wants access to Y” after you’ve signed in, as in essence you are signing in as yourself
Yes, so far applications accessing your Pod are pretty much like applications installed on most desktops: they can access all your data. There was an imperfect mechanism that is still implemented in the NSS server software (running on inrupt.net and solidcommunity.net) and that allows for some very rudimentary restrictions, but that could easily be bypassed and isn’t implemented elsewhere.
The ability to use client application WebIDs is indeed the first step towards allowing more granular control. However, an access mechanism that can incorporate them is yet to be standardised and hence has and will have regular breaking changes and isn’t widely implemented. Then even once it is implemented, there will still need to be an interface that allows people to actually specify how an app will be restricted, and a mechanism for those apps to request the access they need. Thus, while work is happening in that area, if you want to venture into that direction today, prepare for a bumpy road ahead.
Guess I’ll prepare for the bumpy, but exciting road
Is there a way of finding out where certain aspects of the mechanisms are up to, so we can find out what has been recommended / on the road map / completed, and what hasn’t been?
(And possibly a way to help get involved in this process?)