# 2020-01-27 Authentication Panel ## Present * @ewingson * @jaxoncreed * @elf-pavlik * @dmitrizagidulin * @bblfish * @jamiefiedler ## Issues ### [(WIP) Tokens and Credentials section. #37](https://github.com/solid/authentication-panel/pull/37) Dmitri: we discussed it last week Jackson: we need to prioirtize replacement for trusted apps, I think client capabilities should solve it ### [User designating multiple OPs to issue capability credentials #59](https://github.com/solid/authorization-and-access-control-panel/issues/59) Jackson: We assume that capability credentials get included in the token. RS would look at issuer of specific token. We can ignore any other OP. Dmitri: When user has multiple OPs in their profile. RS when verifying tokens they need to check that any of them issued it. I think capability credentials don't seem to change much. User not OP issues them. I see no reason of multiple OPs to re prompt user. elf-pavlik: I don't see big difference between identity credential and capability credentials. Jackson: Let's step back and talk about multiple OPs in general. If user lists multiple ones, RS would look at them as OR, it doesn't require coordinating between them. bblfish: User may have multiple identities... elf-pavlik: we discuss case of user having one identity but using multiple OP. Dmitri: now one can use 'external WebID' and use it with more than one storage. WebID profile would have a statement with `solid:oidcProvider` for each one. Dmitri: With Client Capability Credentails we need to answer where they get stored. Some web applications have backend persistence. SPA/PWA which don't have storage may work different. Jackson: can we use localstorage? just as we store authentication token. Dmitri: User authentication should stay short lived than app capabilities. But I think they can use the same capabilities. elf-pavlik: on different device app could end up using different OP. Dmitri: User should not care which OP they use. Jackson: So storage could get provided by user but not by OP. jamiefiedler: If OP A goes down and OP B gets used. It may require extra consent of permision, but if you revoke on A and than it folls back to B you still have permissions there. elf-pavlik: result of consent screen wouldn't be signed, just used by OPs to issue capability credentials. ### [Client Capabilities: Verifiable Credential Proofs vs. Special discoverable prefix in storage #60](https://github.com/solid/authorization-and-access-control-panel/issues/60) elf-pavlik: @zenomt suggests to just have discoverable prefix and if capabilities are published there RS can trust them. It also requires container storing those capabilities not to allow listing its content. bblfish: we should have protocol where client can pass capabilities by value or reference. elf-pavlik: questions: 1. does result of consent screen gets used across OPs 2. do we use that result as credential or as source of knowledge for each OP to issue credential Dmitri: I think credentail could be shared across OPs. I think User will sign credential not the OP. bblfish: sounds like my launcher app proposal Dmitri: I think of something simpler elf-pavlik: how this would work across devices? Dmitri: encrypted chats like signal, whatsapp, telegram etc. they replicate keys and allow user to password encrypt them. Dmitri: they also allow to register multiple devices. elf-pavlik: I don't see advantage over letting OP sign the credential. Dmitri: I think we may need it anyways. Possibly to early to decide. bblfish: I wrote application which would create its own key. We just need to tie them to webid. elf-pavlik: any thoughts on self-issued OIDC and how capabilities fit there? bblfish: dmv issues you a driver license... elf-pavlik: we discuss user issuing capability credential to the application elf-pavlik: i think we need to have sender constrained credentials.