# 2020-07-20 Authentication Panel

## Agenda

* How do we call document delivered by Adam and Ricky?
* Github issues workflow
* Ensuring proper extensibility - AuthZ
* [Consider IdP to issue Identity Verifiable Credeantial rather than global access token #60](https://github.com/solid/authentication-panel/issues/60)
* [Next week agenda](https://hackmd.io/YPvrnGl5QW6kIQ0CVtBpyQ)

## Present

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

## Minutes

### Github issues workflow

Aaron: We should create issues on github first and optimise time during meetings
Pavlik: We have couple of issues open, how should we process on them?
Adam: We keep a fork and after edits there we push to the repository. We prefer to commit directly and close issues after that.
Pavlik: Maybe you can link to specific commit that resolves the issue

### How do we call document delivered by Adam and Ricky?

Pavlik: I recall Ricky suggesting that you deliver First Public Working Draft
Ricky: Yes, I would consider it First Public Working Draft, but you can consider it Candidate Recomendation if you decide this way. Given last week conversation FPWD sounds safer.

### Ensuring proper extensibility - AuthZ
#### [Consider IdP to issue Identity Verifiable Credeantial rather than global access token #60](https://github.com/solid/authentication-panel/issues/60)

Pavlik: explaining the issue above
Pavlik: Dmitri why did you decide to go with Identity VC
Dmitri: The general idea is that VC is a set of claims about subject with signature and proof mechanism.
Pavlik: What about access token use in you draft
Dmitri: It was mostly intended for backwards compatibility. Some application only access user's own pod.
Henry: I was thinking about access tokens, how does the client deal with different access controls on diferent server. I couldn't work out how it supposed to work. When you deal with multiple clients you need you token to have semantics. You keychain needs to know which to give to which RS. What if you have age verification credential, how it supposed to be used?
Adam: We took VC out on request. We removed it since we front run implementations. I think Justin suggested that access token is very standard part of the protocol. We are going to address fact that there is a need for authrorization. I can't get on board with removing access token. We try to closely track OIDC.
Pavlik:...
Aaron: If you have multiple RS, you should be able to get single tokens from your IDP and client would create DPoP Proof for each request.
Adam: If you have had id_vc in access token, if you reuse it with multiple RS you are oversharing claims. This could cause privacy concerns.
Aaron: I'm not sure how different access tokens would be diferent with regards with information they provide. If you issue exact same tokens you don't change anything with regard to privacy.
Adam: We reasoned that different RSs would require different claims. Once we took out id vc it seems that you can reuse the same token.
Aaron: Data in VC claim was itself a JWT. Isn't ID VC just another access token?
Adam: VC have their own data model, different from OIDC JWT. There are set of claims signed by authorative party. There are not access token on their own. It supposed to be proof of some fact. You could have age and address claim from DMV and other claims from others authorities.
Aaron: From RS perspective, request could come with OIDC access token. It could come with VC claims, as long as RS can recognise them I don't see any implementations issues around it.
Adam: How to include Identity VC, in the protocol right now IdP produces access token used with RSs. If we want to support ID VC we have a lot of issues to resolve.
Aaron: Just as we have WebID-TLS as one of auth mechansims, it can coexist with WebID-OIDC. By conflating them we make it all complex.
Adam: A wallet could host a credentials, client may want to choose which VC it gives to which RS. If you conflate that with currently proposed protocol - OIDC with DPoP. VC Data Model has been standardised, other protocol parts seem to be TBD. It doesn't seem to functionally work with what we have now.
Pavlik: Do you see a way for party other than IdP take responsibility for authorization?
Adam: If there is combination effective and functional, IdP can provide an access token combined with id token which ...
Henry: It would be useful to write it down. You know OIDC the best.
Adam: I'm not saying we can't do it. There is a lot of open questions. VC folks created a data model for claims.
Henry: My launcher app proposal suggests need for wallet.
Dmitri: VC Data Model do not provision for how to bind identity of subject to claims.
Adam: Ricky and I came in and were presented with idea of using VCs. We discovered a bunch of thorny issues.
Pavlik: To my reading OIDC provides access token to access user info endpoint provided by IdP
Adam: OIDC is build on top of OAuth, IdP acts as OAuth AS. OIDC convey information to the client by id token with information about the user. I don't see a clean way that their intersect. If you leave authorization part, our protocol allows to go to any IdP and get access token from it.
Aaron: I was going to mention SAML entitlements but we are out of time.
Adam: Ricky and I have a lot of changes. We just have to continue the discussion next week.