You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@zenomt: the big difference i think with OIDC/POP is that the app public key (the "confirmation key") is bound up with the id_token and can only be used as long as the id_token is valid. Best Current Practice is for the validity period of id_tokens and access tokens to be on the short side (minutes-to-hours) rather than the days-to-weeks as currently issued by NSS. the user's (trusted) OpenID Provider serves as the periodic uncacheable validator of whatever public key is being used to demonstrate identity. the default thing that happens if i close my browser or turn off my terminal is that anyone who could be acting as me+app will eventually (and soon) not be able to do that anymore, whereas positive action would need to be taken to revoke any currently-valid public keys in (or linked to) my profile.
i have a shortcut in my browser's bookmark bar to immediately log me out of all sessions everywhere (across all browsers and devices) in my OpenID Provider with a single click, just in case i'm worried about any sessions running on a forgotten terminal somewhere. and i can view all current sessions and issued id_tokens in my OP, including to what IP addresses and redirect_uris they were issued.
my OP doesn't issue refresh tokens, and i'm not planning on adding that functionality because there's never a situation where i want something to be "me" when i'm not there.
if an automatic agent wants to do stuff for me, it can have its own webid, and then the problem just becomes one of permission.
Approach above sounds to me like focusing only on user attended use cases. Practically all remote clients running somewhere in the cloud will require unattended access. In addition Service Workers and proposed Background Sync may result in local clients running on device in web browser also using unattended access.
The text was updated successfully, but these errors were encountered:
my OP doesn't issue refresh tokens, and i'm not planning on adding that functionality because there's never a situation where i want something to be "me" when i'm not there.
We can discuss requirements on refresh tokens in dedicated issue(s).
if an automatic agent wants to do stuff for me, it can have its own webid, and then the problem just becomes one of permission.
We discuss all software agents having their WebID, I think User should delegate access to them in the same way, no matter if software agent stays attended or unattended by the user.
I will close this issue for now, we can reopen it if we ever see need to distinguish when software agent acts attended by user or unattended. I think with refresh tokens in use we may actually not have straight forward way to make that distinction.
Capturing something from the chat to have better track on this conversation: https://gitter.im/solid/app-authorization-panel?at=5d79b986b9abfa4bd3923adc
Approach above sounds to me like focusing only on user attended use cases. Practically all remote clients running somewhere in the cloud will require unattended access. In addition Service Workers and proposed Background Sync may result in local clients running on device in web browser also using unattended access.
The text was updated successfully, but these errors were encountered: