# W3C Solid Community Group: Authentication Panel

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

## Present
* Aaron Coburn
* Abel Van den Briel
* Laurens Debackere
* elf Pavlik

---

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

---

## Agenda

### Issues

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

### Open PRs

https://github.com/solid/solid-oidc/pulls

### Test Suite location

### Dynamic Client Registration

## Minutes

### Issues

* AC: We have talked last week to get through bunch of the issues and have v0.2 by the end of May.

### Open PRs

* AC: Making progress moving through the issues
* eP: Small PR shortly before the meeting, clarifying terms and linking them to definitions

### Test Suite location

* AC: In the past we had it in the solid organization. There was reorganization of github org including moving most of the repos out. Suggestion was to move it to inrupt organization. There also was suggestion to move it into solid-contrib. I don't want to move it around. We already point from the publish spec to the old link since it was recently moved. I think we can host it in solid-oidc repo, as stable as editors draft itself. This way we wouldn't need to move it around.
* eP: that makes sense to me, then we can collaborate on the code

ACTION: AC to make PR to add the test suite to the Solid-OIDC codebase

### Dynamic Client Registration

* AvdB: Noticed that Inrupt PB uses dynamic client registration (DCR) as a default
* AvdB: why using that as a default? even when the issuer has disabled DCR
* AvdB: what is the recommendation for how an app performs authentication
* AvdB: esp, since DCR is not part of the Solid-OIDC spec
* eP: the Inrupt authn client does support client identifiers
* AvdB: as a general example, is this something we can generally encourage? (client id documents). DCR is not a MUST in the spec
* AC: There are couple of issues. What the flow should be and what it is as seen by a particular application. What it should be it is for the scope of this group, when it comes to what a particular implementation is doing it is often up to that application to choose their implementation.
* AC: Application first needs to discover capabilities of that OP, if it supports DCR, if it supports client identiefiers. If OP includes `webid` scope than it implements Solid-OIDC and supports client identifiers. A client (an app) should be using one of those client identifiers. If it doesn't, for example for testing, or wants to behave as ephermeral client, it can use DCR.
* ...: For pod-browser it might be a bug.
* eP: DCR is also problematic for client authorization. For instance, in the context of ACP, the default should be no access. Unless the policy states "any client has access", a DCR-registered client, that app would likely not be able to access anything.
* ...: interop panel has a heavy emphasis on a stable identifier for clients. In the interop panel, these identifiers are used to attach access controls
* ...: in real-world scenarios, we should really suggest using client identifiers
* AvdB: in the examples of Inrupt PodBrowser and Penny, they use DCR by default, even in the context of the same browser session. This overloads the issuer with useless clients. Using client id documents should be the general use case
* AC: I agree. You may be noticing the interplay between implementations and specifications. Given that Solid-OIDC didn't have stable published version for so long, there are multiple ways of implementing things. Up until fairly recently client id document wasn't boradly adopted. I think penny pod browser has been implemented around a year ago. When it was originally written, client identifiers might not be well understood. We haven't had a stable spec to point to, I would be interested to see where the applications will go. Client IDs provide much stronger identity for the clients.
* AvdB: Maybe penny isn't a best example but inrupt pod browser seems widely used by the community. Maybe post an issue on the Inrupt PodBrowser github
* AC: Pod browser has very recently started to support client id documents. It still has cases where it doesn't work. For me the question is what AuthN panel can do to improve the situation with implementations. We can have good patterns documenting how authentication flows work. It can include improving the primer. Also including better information why it is useful, explaining why it is preffered over DCR. Nicolas is very involved with client tooling. One of the issues is that there are so many permutations of what servers support, clients need to be discovering what particular server supports.
* AvdB: Using the PB example since that was a common starting point. Currently, Client ID documents are a SHOULD not a MUST (same with DCR). There may be reasons not to force clients to use client id documents, how can we better encourage people to use these.
* AvdB: let me know if there is anything I can do to help with this
* AC: There are so many permutations since there are so many contexts where clients try to authenticate. Give all of them we can't always say that client MUST do it this way. We are also trying to move ecosystemm along in step by step fashion. If we don't allow other mechanisms than we get into compatibility issue.
* eP: I'd like to consider making Client Identifiers required for an OP, otherwise it's not Solid compliant. That would also give more confidence by the client.
* AC: It would be helpful to add paragraph that states that OP MUST support Client ID documents.
* ...: There may be ambiguity with regards what is and what isn't dereferencable

ACTION: AC to clarify requirements for OP support of Client ID documents

* AvdB: is there a case where the `client_id` value is dereferencable but _not_ a Client Id Document?
* AC: I think there are 2 parts. 1. If it is dereferencable, if it is 2. Fetch the document and check if it is `application/ld+json`, it must be valid JSON, it also needs to use the normative `@context`.
* ...: Let's say we have some other specification which also defines dereferencable client identifiers, not JSON-LD. When OP tries to dereference it, it would need to have condition based on the format of the client id document. Even if both are JSON-LD it could check for the `@context`.
* AvdB: if it is required that an OP is required to dereference these client_id URIs, then it makes interop much easier to achieve.
* eP: the only case when it's not a client identifier, it's an identifier issued by the OP, which will be pre-registered by the OP. The OP can then just check if it's one of these other formats, it can use that; otherwise, it can just dereference the URI as a client identifier.
* AC: This is how I implemented it.
* eP: even for static registration, an OP will still manage these identifiers
* AC: This is pretty much my experience with implementation. The identifier is either one that was created by OP, or external ones which would be Client ID IRIs.

### UMA updates

* eP: I'd like to check with Laurens on UMA
* LD: I am working with the CSS project, having trouble with DPoP during the claims pushing stage. This is unclear on the Solid-OIDC side. This could be an opportunity to specify an IRI for a DPoP-bound ID token.
* AC: The way I've done this, in one stage you may be providing ID Token. When you push that claim it may perform validation of that ID Token. Also part of this validation is validating the DPOP binding. The part of this interaction involves DPoP header. The format is definitelly OIDC ID Token with some extra claims. One could argue that it is ID Token but also argument can be made that it is a differetn claim.
* LD: My problem is mainly getting references to UMA and DPoP as normative references. DPoP defines use with access token.
* LD: UMA doesn't define the use of DPoP, then there is nothing in the request body to tell the AS how to handle these JWTs
* LD: In UMA, we're using an IRI but there is no link to DPoP
* eP: We have discussed having Solid-OIDC UMA as a separate specification document where this could be normatively defined along with all of the UMA details.
* LD: That would be a very good idea, which could enable other types of claims that could be provided during the claims pushing stage
* AC: One thing that we are trying to do with UMA is normatively require use of the Authorization Server, but we don't want to limit it to UMA. There may be different approaches to Authorization Server. We try to balance those two competing needs. If one uses UMA we want to provide all the requrirements.
* LD: I think Pavlik's proposal makes some sense. UMA details can be in dedicated document. It could also specify the details about DPoP-bound ID Token with webid claim.
* AC: this makes a lot of sense and it really valuable feedback

### Alternative flows

* LD: One small question about the status of the alternative flow document
* AC: We have been busy with publishing FPWD of Solid-OIDC. I think defining alternative flows is next priority. Defining it on OIDC level it may be problematic. Client credentials are OAuth2 flow not OIDC.
* LD: Once Solid-OIDC settles, I would be very interested in contributing to these conversations