# 2020-08-24 Authentication Panel

## Agenda

* [Editorial updates on OIDC Authentication #71](https://github.com/solid/authentication-panel/pull/71)
* Continuation from last week: mechanism for client identification
* Second draft + time frame for final draft
* Bikeshed
* [Next week agenda](https://hackmd.io/E90fJSe2QbGdr9-9GMqQLA)

## Present

* Aaron Coburn
* Ricky White
* Jackson Morgan
* elf Pavlik
* Justin Bingham
* Emmet Townsend
* Sarven Capadisli

## Minutes

### [Editorial updates on OIDC Authentication #71](https://github.com/solid/authentication-panel/pull/71)

- Sarven: I addressed all the comments minus one related to Bearer access token.
- Ricky: Thank you for PR. Severl months ago we agreed that we wouldn't do PRs until we deliver the document. Adam and I work in isolation and it gets messy when we have to rebase etc. Second version is going to come soon, it will have some substantial changes. It will overwrite language in the PR, I would prefer not to merge PR. At the same time I will take note of changes from PR and incorporate them in our next version.
- Sarven: I acknowledge that it was discussed but I would like to challenge that. If the work happen in other space, the group can't see always the latest state of the draft. I think this may be more efficient way to work.
- Ricky: I agree but unfortunatelly what's efficient for the group and what's efficient for Adam and I can be different thing. Hopefully after we finish client identifiers today I can deliver 2nd version of the draft. We agreed with Inrupt that Adam and I will deliver 3 versions of the draft which will give you FPWD.
- Sarven: We operate under W3C community group.
- Emmet: It is moving under the public repo now.

### Continuation from last week: mechanism for client identification

- Aaron: Last week we discussed with device code flow, I looked into that and don't see anything problematic.

- Aaron: In soclid ecosystem device code flow is not supported or used at this moment. I agree that it would take a little bit of work to have it working. IdP would indicate if it supports that flow, this grant type has iri so OIDC config could
- Justin: I agree that solid ecosystem is not utilizing device code flow yet, but the promise of solid suggests that we should support device code flow. People should be able to use all kinds of devices with solid ecosystem. It may not be the highest priority I think it will see use. It could also lead so some innovation.
- Ricky: I'm rewriting this part. Unfortunately I wasn't here last week. Aaround caught me up a little bit. I think this is the last big thing we need to fix. What the WebID may look like with regards to client WebID.
- Aaron: `client_id` already exists. Once we dereference this WebID of client, in this document for users we have `solid:oidcIssuer`, for clients I would suggest to have `solid:oidcRegistration` which would be string literal with JSON containing `redirect_uri` etc.
- Jackson: We spoke above it before. What this JSON would have and what can't be represented in RDF. In my proposal we would have `web_redirect` and `ios_redirect`, possibly it would also need to have `android_redirect`
- Aaron: For this flow we generally talk about OIDC, RDF has nothing to do with it. I don't think we should try to stuff everything into RDF.
- Pavlik:
- Aaron: Client registration is provided as plain JSON. We would have to spec the whole registration vocab etc.
- Aaron: We want display information about the client which are well defined in JSON. We would need to redefine all that. Even with JSON-LD we would have to use specific context and ensure that each server supports it. We may end up with serialization much more complicated for the backend to process.
- Justin: ... When we talk about small piece of data to satisfy protocol not based on RDF, it sounds reasonable not to force RDF there. There could be a middle ground.
- Ricky: An example needs to go into the spec. We need to be a priority.

### Second draft + time frame for final draft

- Ricky: I would like to do it by next week. We agreed to major changes happen by next draft, 3rd draft would be only editorial work. After two more meetings I will not be able to attend meetings any more. I still will be actively working on it.
-

### Bikeshed

- Ricky: I don't have experience with bikeshed.
- Justin: I write a ton in bikeshed on daily basis. I'm open to help any time with it.
- Ricky: When we deliver FWPD do we need to help with publishing it to W3C.
- Pavlik: Maybe Justin could make PR which adds bikeshed?
- Ricky: I would prever to do it myself since I need to later continue with bikeshed format.
- Sarven: W3C is not involved with CG document publishing, we can do it anywhere. I would like to bring up license we publish it under. We have agreement to publish specs under solidproject.org namespace.
- Justin: We have a setup to automate publishing current mater branch

### Actions

Pavlik: To make edit to README explaining not to make PRs untile 3rd version arrives from Adam and Ricky
Pavlik: To create tracking issue for Device Code Grant
Pavlik: To create tracking issue for client WebID Document
Ricky: To deliver new version of the draft