# W3C Solid Community Group: Authentication Panel

* Date: 2021-10-11T14:00:00Z
* Call: https://meet.jit.si/solid-authentication
* Chat: https://gitter.im/solid/authentication-panel
* Repository: https://github.com/solid/authentication-panel

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* Aaron Coburn
* Michiel de Jong
* elf Pavlik
* Pete Edwards
* Nicolas AS
* Barath

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md)
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Sarven

### Introductions
* Pete Edwards (Inrupt): working on conformance test harness that allows it to link to spec and produce reports. looking at this meeting to see how we do OIDC tests and whether things needs to change in the harness or fits..
* Michiel: used to work on Solid OS.. help built oidc server. .. part of the WebID provider tests.. simple: login and .. to access a pod. uses a headless browser called [puppeteer](https://pptr.dev/).

---

## Agenda

* SC: Please provide feedback to [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/pull/319/).
* Test Suite discussion [#22](https://github.com/solid/solid-oidc/issues/22)
* OpenID Provider/IdP (OP)
* Resource Server/Pod Server (RS)
* Relying Party/Solid App (RP)
* Open PRs
* [Remove solid:PublicOidcClient](https://github.com/solid/solid-oidc/pull/48)
* [Add webid scope requirement](https://github.com/solid/solid-oidc/pull/49)
* [Add support for link header discovery](https://github.com/solid/solid-oidc/pull/50)
* WWW-Authenticate Header [#25](https://github.com/solid/solid-oidc/issues/25)
* Documentation of supported spec features [#195](https://github.com/solid/authentication-panel/issues/195)
* Interest in meeting with AuthZ panel this Wednesday.

---

## Topics

### W3C Solid Community Group Meeting Guidelines
URL: https://github.com/solid/specification/pull/319/

* SC: Please provide feedback. That's all.
* AC: Generally +1 to anything that's not cumbersome.

### Test Suite discussion
URL: https://github.com/solid/solid-oidc/issues/22

* AC: Some context: right now we have a couple of different tests. The primary (my impression): it is about testing the Solid protocol. Which largely consists of operations on the server. They all rely on the fact that the server retrieved the access token.. It is a bit of a hole for Solid OIDC spec .. We are trying to figure out how to fix that. Best approach doing this kind of a structure. One of the challenges: the regular test harness and test suite. In context of Solid oIDC. Three thigns that needs to be test: 1) iDP 2) resource server - it is getting a lot of tests 3) relying app - we odnt have any/much testing that. One of the challenges with these kind of test. in OIDC: the typical flow used by clients.. it is actually left to implementations to define what happens at the login stage. .. all of that is implementation specific. wanted to start that with context.

* MdJ: You're right when you have wac and crud tests.. for the crud tests you can also run them on localhost with auth turned off. .. you're testing part of the storage server - the RS. But for the RP we have nothing. I guess that'd be hard to test. Need to check app / need to interact complex way.. we don't know much about the login flow. we do know about the discovery OIDC endpoint.. and the token you want to receive. and we have the webid provider test.. those are testing IDPs. there are three versions of it. it can 3 tests.. NSS, PHPSoliverserer -- using curl -, NextCloud - turned out to be more difficult. the login screen is protected so it doesn't seem to work for curl. so we use the headless browser. we refer to CSS elements.. find the box? .. it expects the redirect.. to follow etc. these tests do exists for only those servers. they run in node / pupeteer. they work.. testing discovery to see all things ar ethere.. test the login flow with the redirects and whatever flow is returned.. what's returned from the browser.

* AC: (Authorization Code flow)

* MdJ:

* eP: I'd like ot be par tof the common test suite.. and what's implementation speicifc ones. for oidc we have .. it can be biometrics / client certificates.. i think we wan tto test that as part of the implementation test suite.. whoever maintains. which part of the solid oidc and ??? we should separate which are the solid oidc specific ones.

* AC: Rhetorical Question: when M was describing implementation specific code.. as more implemetations come along.. I would forsee a lot more imp specific code. Is there a structure that we can develop that will allow us to avoid much code? .. within a single test suite.

* PE: to complete the picture on the cts. it has the ability to refresh tokens on the normal auth flow and client_credentials. it just uses them for the sake of testing other things? for example, there is specific code around CSS.. so we have examples around specific servers but not coherent set of tests.

* AC: I suggest an answer to my question from before: one way to do this: to test the OP.. (not the other two areas) across implementations. what i'm suggesting is: it could be an entirely browser based app. basically a static JS app. leading the oidc flow for a given browser.. as you proceed in that flow it can check a number of things. have that code generate a report e.g. i have js (terrible but.. it sits online and use it frequently... what is the structure of the id token and access token. https://people.apache.org/~acoburn/solid/ is bare bones. If you do login and give the URL of the issuser, ... from there if you were to take that approach we can simply then check the values to see if it conforms to various requirements or features of the spec.

* MdJ: That looks useful. It could test any IDP no matter the interaction. as long as the human does th eclickcing.. if we wan tot be aware / test the areas to instruct the user e.g. type in the wrong pw to see wha thappens.. consent to ?? but not to whatever. maybe the instructions are to login and yes to everything.. but then there are 5 different scenarios.. need to login but not something else. there are advs to automated tests, ci requires a human being. let's have both especially it can be open ended for any IdP. will link to it.

* eP: The tsts should be run against live open id provider. ?? if we ask them to deploy ??? could be modified in somew way. can we find some common way that can allow impelentaers to have limited burden.. to provide the test suite way to get implementation specific tests. perhaps to give a cookie.. if we can think of a way, less burden on implementers .. so move that to imp side if they want to get that fomr the test suite

* PE: we need the ability to setup artifacts, either that has to be through API or agree in advance with server implementers on server states.. and need the ability ot tear down.. either have an API ??? we have different tests and don't want to clash with tests

* AC: We can be careful with scoping: we're want to test solid oidc, rather than all of openid connect, whereas solid oidc builds on openid connect... but don't need to test every failure mode that openid connect defines. that'd be a lot to bite off. i don't know if that needs ot be a requirement. if solid oidc tests.. so calle dhappy path, that'd be sufficient initially but it'd be good to test other permutations.. but in terms of prodigin incorrect credentials et.c. i don't know if we neceessaril yneed to test that.

* eP: For this imp specific test auth OPs: somehow the cookie could be set.. can we maybe hav ea common wa yto obtain that cookie? trying to look what'd be the place out of scope.. and ask imp to provide something that the test suite doesn't have to ?? will do some research.

* AC: this gets to Pete's question. what is the mechanism by which server side test ?? interactin gwith RS. one of the chalelnge swith openid connect. eg client credentials, .. a lot of permutations. b/c we are building on top of openid connect.. we are only mandating openid code? flow. some of hte systems do this.. providing facilities to refresh .. test suite can make use this .. but not sure if it needs to be standardised.

* MdJ: we use the cookie trick for WAC tests but it turned out to be confusing for implementers.. it worked there to have one call to get the cookie.. but at ht esame time the login screens are part of what you are testing. ?? normally you hav ea login and consent screen.. so it is only partial.. I like Aaron's remark.. are we allowed to login at this IdP.. that'd be great then we can see wha tthe format is.. if expiry is valid or slashes on the IdP.. or some other incompatibilities. So for that manual tests are perfect. For automated tests.. that'd be something more for implementers want.. setting cookies ??? you'd probaly want to use a headless browser to go through screens.. which is what you (seem?) to be doing. so it'd be hard to generalise. we'll almost necessarily have the automated test will never be universal because it is open ended on how UIs work. so manual test would be useful to add what we have now. There is more use in putting energy with what Aaron started with manual tests.. we could extend ??? that'd be not one test suite that can handle all IdPs.

* eP: we could start for all conf classes. what we want to test: i don't think for solid oidc we want to test the login op. imp are encouraged to test but i don't think that's part of the common test suite. what we could start is what we want to include eg format of tokens.. the login screen i don't think will appear there.

* AC: this is good conversation. would like to move forward with a specific plan.. we have a need for automated tests for ci.. but thats more than conformance testing.. it seems manual but browser based. I'm happy to.. for the code, take as an action - not this week - to basically take that code as starting point, clean it up.. so that's actually testing what solid oidc is testing.. just a starting point to see how we model these tests. there is an open question if this is part of the solid oidc repo or different.. but public somewhere.

PROPOSAL: take the code in the URL mentioned above as a starting point for OP conformance testing

* eP: +1 as separate repository
* AC: +1
* NAS: +1
* MdJ: +1
* PE: +1

RESOLUTION: general agreement. use separate repo. solid-oidc-tests

ACTION: SC to create solid-oidc-tests

* PE: one thing we've been doing is going through tests to see what's identified in specs.. we identified what we want to test.. automated manually. when we are reporting we can link back to that spec.

* AC: that's critical. really being clear about what we're testing.. and for all of those things we have tests.. another proposal is to take as an action to list out / identify.. all things in solid oidc that need to be tested.

ACTION: write down all of the items that should be tested for Solid-OIDC and ensure that each item has an identifying URI -- AC (not this week but will do)

* PE: we can enhance that .. e.g when we have a manifest file to know if it is manual or automatic..

* AC: makes sense.. any metadata to identify what we are testing.. (as well as how we are)

* AC: we can write down all requirements.. and refer back to the spec but open to other suggestions.

* SC: make sure identifiers are in the spec..

* AC: That'd be part of the review.

* eP: if you wan to do a draft PR, I can help.

* AC: thanks.. that will involve iteration.

* AC: should we try to wrap up this discussion and continue next week.. or press on? we also have open PRs that we need to go through. Noting eP's +1 to rioritze testing due to parcitpation

* MdJ: who nees to be test for that paragraph.. is this req on the idp or RS or RP.. in general, it is not part of the oidc spec.. but it does play a role in solid app and pod. in that auth dialog which pops up ahwn eyou login.. even when proven identity but not get access. you also need to somehow test whether user consented to using that app. some will be reqs on apps. was curious whether the manual tests: for the idp or .. extend those to ... authorize this app. maybe even test apps.

* AC: this is entirely focused on OP, whether w should extent. I might wan tot think abotu tha tmore.. more inclined to keep them modular..because the code ends up simpler but not opposed to testing both.

* eP: some of the things ar erelated to authz. that brings us back to issue: reconcile the work in authn/z panel.. and how they're combinging. we can pick it up in the authz-panel.. to coordinate.

* AC: it is potentially going to get more complicated ongoing conversation... eg. UMA based flow. that's some variability that we need to consider for any testing scenario.. that's why i wanted to keep the tests separate.. how an implementation pull these things together.

* AC: we have n OP, RS, RP. we talk about OP/IdP. in terms of RP/app. as MdJ points out.. let's start with what's easier, namely the RS: if we are able to design something.. and this is for the test suite.. effectively to test the RS, there is a hook - get me an access token, and we don't define what that means but if you're able to get the AT or id token from the IdP.. that could be the path forward for how we handle the Rs testing..

* eP: that compliements the RP, client and OP. we could safely test the client to OP interaction. we can test the RS interaction.. and for the RP/client.. that' dbe impacted by authz. we should take that into account. co-dependency with the authz.

* AC: there's been some work in the past: basically create a mock IdP.. that might be helpful in these RS OP interactions.. if generate token .. with limited access to that webid, you can then begin testing that RS, one thing tha tmay make things easier: build out or reuse.. existing infra. hac mock idp.. that generates valid access otkens for a well known webid, if the RS unde rtest give slimited permissions to that well known webid, then you can beign to test RS. i think ther eis some prior art for this.

* eP: it'd be great if you start .. and we can pick up the conversation.. as it is not currently written down.. what would be tested on the RS side. e.g we could test www-authenticate .. but that doesn't involve authz. maybe we can all out another meeting with test suite panel.

* AC: we can continue this conv in async and also in future meeting.. once we create this test suite repo, for the solid-oidc spec.. I'll put a note on gitter channels and ivnite people. I do know that Pavlik has something small to bring up re authz panel..

* eP: coordinate over gitter chat. i can write down more about the overlap. impact on both panels re interaction with the RS. we can start conv this week and regularly pick up the parts that are related.

### Topic
URL:

* name: text
*

PROPOSAL: text
* name: +1,0,-1
*

ACTION: text