# 2020-04-06 Authentication Panel

## Present

* @jaxoncreed
* @elf-pavlik
* @bblfish
* @dmitrizagidulin

## Issues

### [Upgrade Approach](https://github.com/solid/authentication-panel/issues/45)

- Jackson: In last meeting elf expressed concerns that current mechanism may not be feature proof for restricting client access.
- Dmitri: Why?
- Jackson: Currently tokens seems to say I'm the user using this app and it can do everything I can do.
- Dmitri: We can see current mechanism to receive one or more claims with proof of possesion mechanism. Currently we still use scope mechanism, just having it 'pod wide'. If ACL contains client restrictions and credentials presented don't have it, RS can reject access.
- Jackson: We should avoid having double upgrade. I wouldn't want to require people to do upgrade more than once.
- Dmitri: Waiting to figure out client constrains before we upgrade ecosystems sounds reasonable.
- Henry: the advantage of the launcher app is that you may be able to upgrade more easily.
- Jackson: We want to define flexible system that doesn't require 'upgrades'. For that we don't want auth to continue moving.
- Jackson: I have 4 different scenario:
- 1: we delay upgrade process till client constraining access control is done
- 2: we figure out best way to go forward with deplying solid-auth-fetcher with old token
- 3: we go with current upgrade knowing we will need another upgrade
- 4: we release solid-auth-fetcher but we don't go with upgrade of ecosystem until we solve client sontraining
- Jackson: currently there is no open implementation of server supporting new token
- Dmitri: I plan to add support for new token in my NSS fork
- Elf: In my opinion we should go with the 4th one so that we have something available to experiment with.
- Dmiri: I also see 4th option as best one
- Elf: It would be nice to after upgrade have build of solid-auth-fetcher that doesn't include legacy protocol support
- Jackson: yes it will be possible

### Use cases driving requirements for various ways to define polices that restrict clients access
- Elf: My main intention is to take a step back and clarify the use cases. I don't see it that practical to have client constraints defined in the acl resources. I can only see it used in an enterprise situation. I think we should clarify that first. Because if we want to have policy that applies accross multiple instances of storage, I think it would be useful to clarify the difference between resource-controler constraints and user constraints.
- Henry: Elf makes this point about white and blacklists and I think that one should solve this with the ability to put acls within acls. It doesn't seem like blacklisting a client for an entire website is good. People say that you don't want to edit an acl for every resource because if you change an acl you have to upgrade everything. How do you affect ACLs that affect many resources simoultaneously.
- Elf: I see that henry brings a possible solution and we shouldn't do that until we have clear requirements. We have more of this in recent meetings, and if those requirements seem more restrictive on solutions. So it's better to take a step back and make documents.

### [Technical Objections and Concerns with Proposed DPoP + VC Scheme #47](https://github.com/solid/authentication-panel/issues/47)
- Jackson: @acoburn works on trellis server and he has some comments. He doesn't find those objection compelling. Having puslished darft makes it still further along than anything else that isn't. He has answers for practically each of @zenomt's objections.
- Dmitri: I see it great to have as much critical eyeballs as possible. I overall agree with @acoburn that any of the objections are heavy enough to change the course.
- ...: As for drafts, we don't have many choices, multi RS cases are not handled by that many specs
- ...: Keys generations is one time
- ...: Registration not that impactful
- ...: Lates iteration relaxes requirements on `jit`, as spec writes we can address concerns of extra overhead. If I query 3 different RSs I may need to create DPoP proof for each of the RSs. @zenomt's worries that within one RS client will need to create DPoP proofs for each request.
- Jackson: Signing im my experience is very lightweight
- Elf: That jti it seems like a dpop proof requires a htu, and hti. So, you need a proof generated for each uri.
- Jackson: @acoburn suggested that simple key-value stores can scale horizontally well
- Dmitri: OIDC supports custom claims so we only take advantage of that when including id_vc in id_token
- Dmitri: When it comes to dynamic registration I think we need to address it. OIDC has dynreg optional.
- Dmitri: As for Implicit Flow we alredy follow latest best practices and don't bring anything specific to solid.
- Dmitri: OIDC has two mechanisms for custom claims but none for custom response attributes

### [Initiating User Registration via OpenID Connect](https://github.com/solid/authentication-panel/issues/46)
- Jackson: It's based on conversation with one of the companies we contracted to build apps for solid. Apps should have login and register button. OIDC often assumes that you have already registered with OP before loggin in with the client.
- ...: Nothing in OIDC spec dictates prompt for registering. It only dictates prompt for loggin in or giving consent. I linked to draft that mandates prompot for registering.
- Dmitri: I like prompt parameter and find it useful. I don't know if app developers will find it useful.
- Jackson: App developer seem to want ability to initiate the 'sign up' process.
- Elf: I think we should carefully consider the user experience because if a user uses different apps and they sign up for different identities that's bad. I think it's something we should just say that it's common nowadays, but it might not be the best for a solid ecosystem.
- Jackson: I wrote an article about it before. Optimally somehow in the web browser, once you sign-up for something browser will remember which identity you used. It either requires you to use browse extension or native support in browsers.
- Dmitri: I would like to bring credential handlers APIs. Possibly we will have helpful solution already developing. Already existing as polyfill, unclear when browsers will implement it. Both Chromium and Firefox expressed intest to implement it.
- Henry: Does it work with Verifiable Credentials
- Dmitri: Credentials Handler API, allows users to choose their own 'wallet'. It generalizes well know client certificate pop-up.
- Henry: Is it tied to domain? Or you can use credentials across domains? Also does it pop-up all the time?
- Dmitri: The problem with certificate pop-up relates to server initiating the request for client cert.
- Henry: Does it remove need for WebCrypto API?
- Dmitri: No it uses it under the hood, it is a complementary solution. It gives WebCrypto API storage mechanism that works across domains.
- Jackson: Let's have we have that cool system. We still would want ability to initiate 'register' route. For clients using solid-auth-fetcher, when clicked 'register' it would first check if user already uses something if not than trigger the register.
- Dmitri: I agree with elf that UI wise we should make sure that user doesn't get impression the register with client / app. They register with storage provider.
- Elf: identity provider
- Dmitri: true
- Jackson: I described on-boardin and 3 different aspects and user can arrive from any of them. The IdP, the client / app or storage.
- ...: If user arrivs from app, they may need identity and storage.
- Jackson: I think strong recommendation is that WebID Profile should be tied to IdP. So IdP would provide small storage for that WebID Profile.
-