Login - differentiation between "total" access and "app" access

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.

With reference to Authenticate Client Applications (Browser & Node.JS) — Inrupt JavaScript Client Libraries I fully support that this is the way to show what apps are accessing what data, and that the client has to “log in” to provide their data to this way. However - I’m unclear as to whether an app has to register / create a webid using that URL - that doesn’t seem to be overly clear to me.

Running an app.
App requests a name and DOB that is stored is users pod
user logs in.
App gets the data stored against that users pod, which has been previously granted

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

  1. Opening up your entire POD to an application by signing in
  2. 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 :slight_smile:

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?)

I’m not sure as I’ve never been too closely involved with it, but some relevant starting points are probably:

And possibly the folks in solid/specification - Gitter have some additional pointers.