## 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