# W3C Solid Community Group: Authentication Panel

* Date: 2022-02-28T15:00:00Z
* Call: https://meet.jit.si/solid-authentication
* Chat: https://gitter.im/solid/authentication-panel
* Repository: https://github.com/solid/authentication-panel

## Present
* Nicolas AS
* Elf Pavlik
* Abel Van den Briel
* Kushal Das
* Aaron Coburn
* Laurens D
---

## 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
* Nicolas AS

---

## Agenda

### Pull Requests
https://github.com/solid/solid-oidc/pulls

* [Alternative Authentication Flows #81](https://github.com/solid/solid-oidc/pull/81)
* [Clarify verifiable claims TLS requirement. #16](https://github.com/solid/solid-oidc/pull/16)

### Issues
https://github.com/solid/solid-oidc/issues

* [Primer: multiple issues #83](https://github.com/solid/solid-oidc/issues/83)
* [Organize sections by conformance classes #65](https://github.com/solid/solid-oidc/issues/65)

## Minutes

### Introductions

* Kushal Das: New to the Solid ecosystem. Director of the Python foundation. Building an IdP to try out Solid. Modifying an existing one to comply with Solid-OIDC. Also looking into implementing a Solid server in python.
* EP & AC: Feel free to join the Solid Community Group in order to be able to contribute.

### Alternative Authentication Flows

[PR#81](https://github.com/solid/solid-oidc/pull/81)

* EP: The PR is ready for merge
* AC: +1
* LD: +1. There has been some feedback from the Solid lab, but it doesn't warrant blocking the PR from being merged. The PR content focuses on use cases around flows which aren't based on browser redirects, which is currently the main approach.
* AC: Non-browser contexts are going to be more and more significant. Scripts, smart agents, IoT doesn't work well with authorization code flow.
* LD: It's important to take a step back, document the requirements, and then be able to build the different flows appropriately.
* AC: Alternative flows tend to be documented in other specifications, such as OAuth2.0 or GNAP. Thinking more broadly about this is going to be to our advantage.
* EP: Merged.
* AVB: What has been merged is not a spec change, but a setup for the change, correct ?
* AC: It is not part of the spec, it's starting point for the discussion on how spec can incorporate those flows. Spec may accommodate them or they may become separate documents. I'm leaning towards having small focused specs.
* AVB: This is a use case we (Digita) are also interested in.
* EP: Don't hesitate providing additional feedback through new issues.
* KD: The place I started from is developing services, and how they should identify. How are things approached: first introduce the use case, and discuss it in the abstract, or first provide a PoC ?
* AC: The proper approach depends. Either a PoC to provide feedback to the impl, which leads to a very precise feedback. If there is a known use case which will be problematic, that's an excellent starting point. Presenting flows and things that you want to do allow discussing whether it is in scope for the spec, and then to write spec language.
* EP: Describing how the webid and azp claims should be used will be useful. The webid is assumed to denote the end user, and the azp the client the user is using, but in the case of users these two may be conflated, as the service may be acting on its own behalf. The service may also be acting on behalf of an organization. Documebnting in your case what the webid and azp would denote would be valuable.

### Clarify verifiable claims TLS requirement.

[PR#16](https://github.com/solid/solid-oidc/pull/16)

* EP: This PR has been hanging there for some time. Related to issue #76. Do we want to require the WebID URL to be https, and would it be even compatible wih the WebID spec ?
* AC: There are two issues. 1- How do you test this ? How can you check that the server implements a secure transport mechanism ? 2- Internals of the OP. This text may go too far. The spec could simply say "When making use of web-based resource, the security of their transport should be considered"
* EP: OAuth and OIDC do rely on TLS, so we'd be aligned with this, but we could be putting extra burden on future approaches eg DID. The requirement would apply to the publishing-side rather than consuming parties (e.g. on webid provider, but not on OP)
* AC: What we currently have is "... must be transported over TLS", which is in the domain of the OP. When it comes to "external" resources, it leaks out of the scope of Solid-OIDC. The SOlid-OIDC spec should not add additional constaints on the WebID spec, even when they make sense.
* KD: How should the recommendations be linked so that developers don't miss them ?
* AC: There is always tention between restating things from other specs or duplicating text. As long as you refer normatively I don't think we need to restaate. Security considerations are not normative but we use normative language like MUST. I see us being inconsistent.
* EP: What about the Client Identifier, it being defined by Solid-OIDC
* AC: In that case it would make a lot of sense for it to be required in https
* EP: The WebID spec does'nt specify, so in this case is it bad to add our own requirements on top, narrowing it of some sorts, like requiring the trusted OP to be referred ?

### Primer: multiple issues

[Issue#83](https://github.com/solid/solid-oidc/issues/83)

* EP: Contributions for Dimitri (i believe keycloak contributor) ? If anyone can help him contribute that would be great.
* AC: Indeed, the primer has been neglected. I'll open some small PRs to try and address some issues.
* EP: Very well, i'll focus on #65. @KD, do you have feedback on the primer and spec ?
* KD: Not necessarily, I'm learning a lot still.

### Organize sections by conformance classes

[Issue#65](https://github.com/solid/solid-oidc/issues/65)

* EP: First step with PR#79 for the WebID profile document. Similar example is the ID token verification, which happens on both the client side and the AS too. How do we want to eventually add the test suite annotations on the conformance classes ? In the case of multiple parties who need to comply with a certain part, eg ID token verification. Could it be identified as an atomic requirement, applied to multiple conformance classes ?
* AC: This kind of spec organization will make things easier for implementers and people testing implementations. Because there are a number of conceptual entites involved, each having its own responsibilities. Unless you understand each of these components, it is confusing who is responsible for what. The new organization intends at reducing this confusion. @KD, since you're looking at implementing an OP your feedback will be very valuable.
* KD: One of the recent changes made the sequence diagram noticeably more complex. We still have a lot of areas to investigate to figure out what responsibilites our software will have.
* AC: It's really great that you're asking the questions to the panel.
* EP: ID token verification is the next step I want to address, without specifying who is doing the verification. Maybe describing a mixin class "OIDC token verifier", and refer to it for different conformance classes
* NS: it would be useful to have these mixin classes, but it might be interesting to consider whether that verification should happen differently, depending on the party. e.g., certain claims may need to be validated differently. May also want to consider having a primary conformance class for how an ID token should be validated, then other conformance classes could refer to that conformance class.
* EP: The specific use case we are looking at is the AS acting as a client to the OP, in which case we want to verify the webid claim as a client. @AC, is it something you've met in your experience ?
* AC: Any server code does full validation of the token. If the client makes use of the values of that ID token, it is good to validate the signature. Needing to do full e2e validation may depend on the use case.
* LD: We have a use case where the ID token is parsed on the client side too. We operate our own OP though, so there is a stronger trust relationship. In the case where your client doesn't have that, full validation mùakes sense.
* KD: in the case of an SPA, should'nt the ID token always be verified ?
* AC: There are multiple ways to approach this. Existing patterns are: 1- asking the user where to start (one or several OP), 2- ask the WbID to the user (tricky from a UI pov). An SPA could store some info in local storage, but it should be always considered as something that may have been tampered with. Then the client may validate the previous value with the user. Another common pattern is to provide a list of common OP, which is only valid when there is a limited number of OPs.
* NAS: The solid-client-authn library does signature validation of the ID token
* EP: Verifying the signature comes form the OIDC spec. Issuer could be validated by the client, and must be by the AS, and the DPop validation doesn't really make sense on the client side since they are the ones holding the private key.

### Open business

#### WebID

* KD: The foundation of Solid is Linked Data, and the WebID is this primary link. Isn't this a very strong privacy concern? This allows strong correlation between the different activities of a single user.
* NS: One user may have several WebIDs which may be used in specific context. Those could be correlated or not.
* KD: if the OP could generate pseudonymous webids, could this allow to mitigate correlation ?
* EP: Pseudonimity limits the access control, which is tied to a single WebID. The WebID is a pseudonym by itself, but it needs to be persistent and global.
* KD: What about the case where mutliple services are based on a single government-issued WebID ? It is a known thing that e.g. SSN should not be used developping an application for instance, as it links the account to a single person.
* AC: What Solid adds to the Web is identity. All of the trust model in the context of Solid starts with th WebID, so calling out what it means is very right.
* LD: In Flanders, the WebID isn't considered as a 1-1 identifier. Rather, identifying claims are added to the ID token.
* KD: I'll diagram this out and come back to the group.