---
# System prepended metadata

title: Untitled

---

## 2020-06-22 Authentication Panel

## Agenda

* review draft from Ricky and Adam
* admin access to the repository
* VC expiration and refreshing
* [Next week agenda](https://hackmd.io/8UKCoZRIROmoDVOcCovz1g)

## Present

* Henry Story
* Dmitri Zagidulin
* Justin Bingham
* Ricky White
* elf Pavlik
* Adam Migus
* Davi Ottenheimer

## Minutes

### Review of the new draft

- Ricky: I've designed this document with no extra, except having placeholders for W3C mandatory sections.
- ...: Out of scope left TBD since we need to decide on the scope first.
- ...: We build on top of OIDC, we don't repeate it just reference OIDC spec.
- Justin: I see section specific to WebID, can we identify WebID as a scheme which conforms to identity pattern. It is important to stay open to adapt to DID down the road.
- Adam: You will notice that spec doesn't dictate WebID format. Everything in the spec should work if youw switch WebID for DID. I find using DID an interesting idea, it gets traction.
- Pavlik: Quesiont about dynamic registration and identifying clients.
- Adam: We made dynamic registration optional, and we require clients to have WebID.
- Pavlik: Any requirements on returned Profile Document?
- Adam: No requirements.
- Justin: Currently we use `solid:oidcIssuer` for user to delegate to IdP. 
- Adam: We mention that client's are untrusted, later they become trusted when you issue token for them.
- Adam: DID has semantic equivalent, which points to authorative document. Do you think we should address trust relation between user and idp?
- Henry: We need relation between identity you present and identity provider you give authrity to issue credentials.
- Adam: We left open how we use Verifiable Credentials. They have trust model based on the idea of having issuer and subject.
- Pavlik: I think we can follow up in issues after we accept the PR.
- Pavlik: Do you have any requirements on expiration and refreshing?
- Adam: In a way we almost create profile for OIDC. OIDC already discusses expiration of tokens.
- Pavlik: What audience do you use in access token?
- Adam: It should be RS
- Pavlik: so client has to request access token for each RS?
- Adam: We discussed it with inupt folks. We also see privacy constraints. Single token shared for multiple RS would open privacy risk.
- Pavlik: I don't see what role IdP plays in DPoP flow.
- Ricky: In DPoP uses keypair and IdP constrains token to the client.
- 

## Actions