# 2020-07-06 Authentication Panel

## Agenda

* [Solid-OIDC Authentication Spec - Draft](https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md)
* Reviewing old issues
* [Next week agenda](https://hackmd.io/-YbKjAv6R_acrogPU1qREQ)

## Present

* Jackson Morgan
* elf Pavlik
* Dmitri Zagidulin

## Minutes

### [Solid-OIDC Authentication Spec - Draft](https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md)

- Jackson: Ephemeral Identity Providers
- Dmitri: I think user may refer to self-issued
- ...: In self-issued case IdP works as pass through. I don't know what client being IdP may mean.
- Pavlik: we have existing issue for self-issued
- Jackson: Possibly self-issued is out of scope for this draft.
- Jackson: "The client presents its WebID to the IdP and requests an Authorization Code.", why is the client presenting its WebID.
- Jackson: Mechanism by which IdP confirms that this WebID is owned by the app.
- Jackson: I don't think the Basic Flow is detailed enough to understand the details of what's going on. Here I outline a process in more details: https://github.com/solid/authorization-panel/blob/master/proposals/TrustedAppsReplacement.md#general-networking-flow
- Jackson: I it common to delegate term definitions to existing spec, for example RS as defined in OAuth2?
- Dmitri: Yes I think it's common.
- Jackson: With dynamic registration, we need to consider if client doesn't have to support it or server. It seems that at least on of them needs to support both.
- Jackson: Aaron implementation used to require dynamic or static client registration and use of client secret to get refresh tokens.
- Jackson: Does client have to request both id and access_token. In authorization request, you want response type ty be code but you also insert other response types as space delimited string.
- Jackson: I don't see mention of sub claim in access token section except in example.
- Dmitri: Why is the audience claim `solid`.
- Pavlik: "Ephemeral clients MUST use DPoP-bound Access Tokens, however, the RS MAY allow registered clients to access resources using a traditional Bearer tokens.". I don't see how RS would tell if client regestered with AS or not. Maybe it tries to address that single-RS use case where RS and AS coupled together?
- Jackson: I find it odd to call out *iat* but not *htu* and *htm* (post in issue 49).
-