---
# System prepended metadata

title: 2020-07-27 Authentication Panel

---

# 2020-07-27 Authentication Panel

## Agenda


* Clarification needed on Ephemeral Identity Providers ([Issue #53](https://github.com/solid/authentication-panel/issues/53))
* Client Registration does not state which entity it's optional for ([Issue #56](https://github.com/solid/authentication-panel/issues/56))
* Logical Analsysis of the protocol [see gitter chat](https://gitter.im/solid/authentication-panel?at=5f15b665b2dad248b6ca6039)
* [Next week agenda](https://hackmd.io/lJp-XvcxRC-s4fcr_24UBg)

## Present

* Aaron Coburn
* Henry Story
* Jackson Morgan
* Justin Bingham
* elf Pavlik
* Adam Migus
* Ricky White
* Davi Ottenheimer

## Minutes

### Clarification needed on Ephemeral Identity Providers ([Issue #53](https://github.com/solid/authentication-panel/issues/53))

Jackson: I see from your response that existing providers means Google or Twitter. When it comes to *user* do you refer to self-issued OIDC?
Ricky: I didn't mean self-issued. In decentralized ecosystem noting stops me as a user to run my own IdP, RS etc. On other hand I can use 3rd party deployment.
Jackson: IdP isn't the user, it's system deployed by the user. It is non normative text, it just tries to say that user can rune their own deployment.
Adam: It's non normative text. 
Jackson: What about 'any client application'?
Ricky: If I want to download an app on my phone or use web application. It could act as IdP as well as client.
Jackson: This sounds like self-issued flow, if client runs on your device. OIDC self-issued flow would need agumentation to work with Solid ecosystem. If we don't address it we should remove it from non-normative text.
Pavlik: We should just focus on roles affecting the flow.
Ricky: I just wanted to explain ephemeral IdP
Jackson: IdP provided by the user is still stable and onlin as long as user relies on it. Self-signed sounds to me more like ephemeral IdP.
Adam: I had discussion with Justin Richer. Notion of emphemeral clients seemed quite central.
Jackson: Ephemeral clients are core. My issue referes to ephemeral IdP.
Adam: I don't want to use ephemeral to describe IdPs. We will come up with different wording.

### Client Registration does not state which entity it's optional for ([Issue #56](https://github.com/solid/authentication-panel/issues/56))

Adam: I discussed it couple of times with Justin Richer. Client registration is not required, it serves a function in OIDC model, to persist notion of that client. We don't want to throw it out but it's now not required.
Jackson: If we make registration optional we need to specify for who. If it's optional for client than IdP has to support case where client does it. If optional for IdP than clients have to support both ways.
Adam: I was refering to clients.
Pavlik: ...
Adam: I agree that we have to say that IdP supports both choices.
Jackson: Dynamic (or static) registration, creates an identfier for client. If there is no registarion what is considered a client_id. Spec doesn't define how to identify client if registration doesn't happen.
Adam: It looks like another loose end. 
Jackson: We should keep in mind that client's can't strongly assert their identity. This applies in a case where user doesn't use compliant user agent.
Adam: What does complian browser mean?
Jackson: I means that redirects are respected for example.
Davi: Compliance is just a base line, it doesn't guarantee valididty.
Jackson: OIDC assumes that redirects are going to go back to the right place. Is not as strong as key based authentication. Dynamic registration is a thing in OIDC.
Ricky: You refer to section in security considerations. It was added regarding to current implementation inrupt has. Aaron uses redirect_uri as client id.
Adam: The browser is under user control.
Jackson: Having redirect_uri being used as client_id is not necessarily best solution. NSS will take it for granted what is passed as redirect_uri. This is an example of registration providing additional trust.
Adam: I don't see how do we resolve it.
Jackson: It may be more trouble than it's worth to have dynamic registration optional. If we don't do registration we need to answer estabilishing client_id. It might make sense to just require dynamic registration.
Adam: Making it optional lets client to do it or not.
Jackson: As we discussed it makes IdP required to support flow with no dynamic registration.
Adam: In early draft we need to acknowledge effort of implementation and not making it burdensome.
Jackson: What is the main benefit of making it optional?
Adam: I want to take it back

### Logical Analsysis of the protocol [see gitter chat](https://gitter.im/solid/authentication-panel?at=5f15b665b2dad248b6ca6039)

Henry: I posted it on gitter (link above). When I'm reading OAuth spec I try to follow what is happening. We have agents making statements. Based on that we can reason access claims etc.

Adam: I understand that you request formal verification. We can ask Justin Richer about prior work on OAuth2.

Pavlik: (in chat) you could do more research around work presented here https://www.youtube.com/watch?v=x8F9ms-uMbU

> CCS 2016 - A Comprehensive Formal Security Analysis of OAuth 2 0
> Daniel Fett, Ralf Küsters and Guido Schmitz (University of Trier)