owned this note
owned this note
Published
Linked with GitHub
# W3C Solid Community Group: Authentication Panel
* Date: 2022-05-09T14: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
* Nicolas AS
* Abel Van Der Briel
---
## 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
### Issues
https://github.com/solid/solid-oidc/issues
### Open PRs
https://github.com/solid/solid-oidc/pulls
## Minutes
### Misc questions
* AvdB: I shared a question on gitter before the call: "The Solid OIDC specification in section 5.1 pertaining Client ID documents: 'When a Client Identifier is dereferenced, the resource MUST be serialized as an application/ld+json document unless content negotiation requires a different outcome.' If the resource MUST be application/ld+json, how would content negotiation require a different outcome? Shouldn't a server just error if a Client ID document is retrieved with a content-type other than application/ld+json?"
* AC: We want to provide clarity on the format of the resource: all clients must be able to expect a JSON-LD serialized resource. A server could *in addition* allow content negotiation to support additional serializations, but JSON-LD is a baseline. The exact formulation is inspired from LDP, but it could certainly be clarified if required. For content negotiation, in the case there is an `Accept` header present, either the server supports one of the requested formats, or not. In the latter case, a 406 may be responded.
* AvdB: My understanding of the formulation is that in the case of a failure of content negotiation, json+ld should always be returned, even in case of 406
* AC: The server would default to json+ld even if the client was asking for another format if the server doesn't understand content negotiation at all, e.g. it is a static file server.
* AvdB: In our deployment, the client identifier is served as a file, and always returns json+ld. Would you say it isn't the most correct implementation.
* AC: That's a completely valid implemention. It's up to the client to check the Content-Type header value before attempting to any form of parsing. There are multiple reasons for which a client may get back an unexpected format, and they should handle this properly. Maybe a 406 response is "most" correct in a sense, but returning json+ld is absolutely correct too.
### Implementation feedback
* NS: The CSS implementation has been changed to include an additional parameter: `iss=<IRI>` ([RFC 9207](https://datatracker.ietf.org/doc/html/rfc9207)). This allows a client to check that the auth code is coming from the expected identity provider. In a closed ecosystem, this isn't a significant issue, but in an open ecosystem, this can trip up a client.