W3C Solid Community Group: Authentication Panel

# W3C Solid Community Group: Authentication Panel * Date: 2021-11-22T15: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 * e Pavlik ## Regrets * Pete Edwards (unless there is something specific to testing on the agenda) --- ## 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 ### Introductions * name --- ## Agenda * [Open Pull Requests](https://github.com/solid/solid-oidc/pulls) * [Add RS associated AS issuing Access Token PR#18](https://github.com/solid/solid-oidc/pull/18) * Should the specification recommend one client authentication method ? --- ## Topics ### Open Pull Requests https://github.com/solid/solid-oidc/pulls #### [Add RS associated AS issuing Access Token PR#18](https://github.com/solid/solid-oidc/pull/18) * EP: /Shares latest sequence diagram/. The changes include adding emojis to identify actors. The moment the client is authenticated is made explicit in the diagram too. The change also include removing the textual description of the auth code flow to point to the primer. Access token has bee replaced with ID token. Accordingly, the audience has been moved from solid (for Access token) to client ID (for ID token). The claim in the ID token associated to the client ID is proposed to be `azp`. The binding of the ID token to a DPoP key is also mentioned. * AC: I've look into the `azp` claim in the past. It is a good thing to have. I do not recall why we decided to use it. It seems like a good fit, so we should look more into it. It looks like it would desambiguate the claims we use. * EP: If we want to issue ID tokens scoped to a specific AuthZ server, then this information would be in the `aud` claim, and it would be good not to rely on this claim to discover the client ID. * EP: The PR does not include the discovery of the AuthZ server. Each actor presened in the diagram should be a conformance class so that they are individually described by the spec, in a slightly different structure. * AC: +1 on reorganizing to frame the conformance classes. * EP: The restructuring could happen in a different PR, but in the current PR should include a description of the AuthZ server responsabilities, and examples of claims in the ID token. The fact that all of this is extensible by othe specs * AC: What approach were you thinking about for the authZ discovery ? including but not restricting to UMA as_uri ? * EP: Yes. I don't have other examples besides UMA, but there may be others. * AC: We want to be clear about expectations not to lock ourselves in a box. We should write something along the lines: the `as_uri` parameter must be included in the WWW-Authenticate header, unless the active authentication scheme requires a different discovery mechanism. * EP: /Updates issue 25 accordingly/. Ideally we should merge this by the end of the month, but we can defer pain points in the existing issues. * AC: since this is a big change, we should make sure people are well-aligned on this. Should we reach out to CSS/NSS maintainers while this is still a draf, so that we have early feedback ? * EP: It would be nice to have some way of linking to the rendered preview of that PR for discussion * AC: We could do this manually if automating is too much of a hassle. * EP: We can move on with the discussion until we are happy enough with it and open it for broader discussion, and only then render it. * AC: It would be good to have a clear horizon for the public feedback. We should be conscious about the fact that the Christmas holidays are coming up and that a lot of people are going to be out at this point. * EP: Worst case scenario, if feedback is too negative with compelling arguments, we can always revert the change. We could agree on merging this this week, and open a 2-week window. * AC: This sounds like a good plan. This is also a good first step to define a step forward, because we stop specifying the role of the OIDC issuer issuing Access Token, but we don't prevent it altogether, which maintians backwards compat * EP: The role of the AS is very clear in the current spec. Do we want to add back some text about where the access token is coming from ? * AC: No, we should only describe what we want for the future, but not preventing the current approach helps ramping up the ecosystem to this flow. * EP: Most likely the clients will be able to detect if the new flow is supported or not. * EP: For the test suite, will the code only test the OpenID provider, or should the test suite cover each individual conformance class ? * AC: The latter would be the direction I'd like to go in. Currently it only focuses on the OpenID provider, but eventually being able to test conformance of Openid provider, AS, Client identifier, and RS. Not sure how to test clients. * EP: Maybe exposing a test server endpoint. Being able to test conformance of client ID documents would be a nice first step, these are minimal requirements. * AC: That sounds great. The test currently tests its own client ID document, but it would be good to go towards testing a permutation of parameters. * EP: Being able to split the conformances tests by conformance class would also make it easier to implement because tests only make sense in the context of a single class. * ### Should the specification recommend one client authentication method? * NS: Using ClientID document prevents us from needing client secrets. Does the client_id needs to be added to request body. Should it be mentioned in the spec. * AC: Good question. We discussed it but didn't take action on it. The main problem with client_id going in Authorization: header. You just need to URL encode client_id if you are using BASIC auth. It may make sense to add non-normative text about that case of URL encoding client_id (URL). * NS: In OAuth2, or BASIC auth. Only having the username without password was supported. * AC: We were not using it * eP: is this for authorization for the resoruce server? * NS: this is for the token endpoint on the OP * eP: in that moment, you would want to use basic auth, but not without a password? * NS: in the library we use, in order to use basic auth, we need a client_secret. There are several auth schemes defined in the OpenID spec, should we recommend a particular auth scheme in Solid-OIDC? * NS: I can open an issue with this so that we can make a proper decision with the proper context. * eP: putting the relevant RFCs in the issue will make review much easier * eP: related to `client_credentials` flow, for clients that do not use the redirect_uri, we should provide information about how this flow would work w.r.t client authentication * NS: there is an open issue about this particular flow * --- PROPOSAL: text name: +1,0,-1 ACTION: text