owned this note
owned this note
Published
Linked with GitHub
# 2019-09-11 Solid App Authorization Panel
## Present
* @zenomt
* @bblfish
* @elf-pavlik
## HTTP Signatures
https://github.com/solid/authentication-panel/pull/20
- zenomt: if we identify app with public key one can have persmissions for this app discoverable from one's own WebId, it anonymises the app identity.
- zenomt: I have concerns with regards to the user experience, each app on each device has to have it's own public key and it needs to get added to that registry discoverable from user's WebId profile.
- ... I think we should consider it -- not neccessary a deal breaker
- zenomt: app will make public key with web crypto, user needs to get it to its registry
- elf-pavlik: I see anyway a need for specialized app to manage authorizations of other apps
- bblfish: in WebID-TLS browser creates the keypair which is nice
- bblfish: (http-signature is in some respects not far from OpenID Connect)
- elf-pavlik: I tink refresh token security compares in some way to private key security
- bblfish: server can't tell difference if browser created the private key and stores it in secure manner
- ... On the other hand, I saw JS technologies research from 2014 [COWL (Confinement with Origin Web Labels)](https://www.csoonline.com/article/2691741/researchers-unveil-cowl-a-new-system-to-protect-surfers-privacy.html) which allow part of application to stay opaque to other parts of application. Parts of this were integrated into JS standards,
- ... but I don't know which.
- ... This allowed a text editor which could have limited access to other parts of application.
- ... Perhaps this would allow Access Control Application to be built that other apps could use in a secure way.
- zenomt: if we identify user + app by public key, from the outside indistinguishable from one generated anywhere else, the keypair could get generated in the app itself in a way that private key could get leaked
- zenomt: we should not expect too much from the user
- elf-pavlik: i see similrar keys / tokens issues with regards to leaking with PoP Tokens approach
- bblfish: http signatures may not be as simple to use for developers as openid-connect or webid-tls (which is built into the browser). (later: on the other hand JS libs can be built to do pretty much anything)
- elf-pavlik: we need to handle different security quirements and can't always assume 'maximum security', sometimes users will be more trusted to decide which apps they can use, sometimes less.
- bblfish: here we get identifiable user + app, not just the user
- zenomt: difference betweeen pop tokens and public keys i see related to duration of the token / key. key will most likely stay longer in the profile.
- bblfish: http signatures works in some ways similar to webid-tls.
- zenomt: with client certificates, browser comes as more trusted agent compared to some app running in the browser.
- elf-pavlik: openid connect doesn't provide way to restrict issuing tokens for specific apps so solid either way will need to innovate here, using id tokens from op or public keys registry
- zenomt: i'd like to think about user experience across devices, how authorization flows would work etc. how user can keep track on all those public keys, cashing implications on servers etc.
- elf-pavlik: i think we should go over all those scenarios for OIDC + PoP Tokens as well as HTTP Signatures, maybe even have side by side comparison.
- bblfiish: good idea
- zenomt: current draft has big disclaimer "Do not use it in production", OIDC has actual standard backing it.
- bblfish: yes, though it is a big improvement to the similar WebID-RSA protocol that Solid used, as Http-Signature has a large community with quite a lot of implementations, tests, ... So not as much adoption as OpenID-Connect, but a lot more than WebID-RSA :-)
- zenomt: we should think pros and cons comparing with other options we have available
- bblfish: I see a big pro in having it very close to for REST and Linked Data and so it fits Solid well.