W3C Solid Community Group: Authentication Panel

# W3C Solid Community Group: Authentication Panel * Date: 2022-01-10T15: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 * Tom Haegemans * Wouter Termont * Matthieu Bosquet * 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 * Nicolas AS --- ## Agenda ### 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) ### Issues https://github.com/solid/solid-oidc/issues * [Organize sections by conformance classes I#65](https://github.com/solid/solid-oidc/issues/65) ### Discussions #### Short introductions * NAS: I'm a developer at Inrupt, working on the SDK * AC: I'm also developer at Inrupt, working on the enterprise server * TH: I'm a cofounder of Digita. We have questions about UMA #### First public working draft * MB: What is the timeline for the FWPD ? * AC: We hope the FPWD to be published within the month (not a hard commitment though). The remaining items to be sorted are: * PR#18 * Reorganizing the sections by conformances classes * Setting up automation and consistency check * MB: Should we take action on updating the primer is updated ? * AC: Definitely, any help is appreciated. * EP: The primer is updated as part of PR#18 ## Topics ### Digita question about UMA * TH: UMA has been written without assumptions about the relationship between the access control and the actual resources. In UMA, the access controls can be kept in the AS domain, while in solid they may be stored in the RS, which feels perpendicular. * EP: These are excellent questions. This Wednesday in the AuthZ and interop panel will be dedicated to this. One of the assumptions in Solid-OIDC is that there's a shared security domain between the RS and the AS, so how they sync is out of scope of the spec. They synchronize to have a single source of truth. The AS can generate ACRs based on ??? in the interop spec. * AC: Let me first comment on OIDC/Oauth2. OIDC descibes how an ID token can be generated, access tokens are out of scope except for the userinfo enpoint. The fact that we've been defining the OIDC profile to issue an access token is fairly non-standard as far as OIDC goes. What we've been trying to do is to align with the spirit of OIDC, which is focus on AuthN, not AuthZ. That's why Solid-OIDC focuses on ID tokens, not access tokens. But when you've removed the access token from Solid-OIDC, then how do you access resources ? That's the change brought in #18. A common pattern is to have an AS (AuthZ Server) separate from the RS. UMA is a mechanism to standardize how the AS, RS and OP work together. * AC: Here are now a couple of implementation patterns informing how resources and auxilliary resources may be organized. 1- The ACR is hosted and managed by the same runtime as the Solid resources, e.g. /resource and /resource?acl. Co-locating the resource and ACR makes it logical to co-locate the RS and AS, under one domain. 2- The ACR is hosted under a different service. The lifecycle of the aux resources should by managed so that e.g. deleting the resource also deletes the aux resource. In this case, the AS and RS may very well be separate, as long as they are kept in sync. * TH: Thanks, I'll look into it more but that answers my questions. * WT: Both the AuthN and AuthZ panel working on this makes it a bit confusing, but these explanations align with my intuitions. * EP: Circling these issues with the interop panel will start on Wednesday. The discovery will also be a topic. ### Add RS associated AS issuing Access Token [Solid-OIDC PR#18](https://github.com/solid/solid-oidc/pull/18) * EP: Regarding normative vs non-normative text for UMA. We should evaluate if we can ensure that implementations which only implement the normative text will still fully interoperate. I have concerns that if the UMA grant isn't implemented, then some compliant implementations will not be interoperable. I would prefer having normative text defining interoperability at a finer granularity. * AC: Note that UMA is not necessarily widely implemented, which is one of the reasons why I don't want UMA to be required to implement Solid-OIDC. UMA is simply one way of doing this within OAuth 2, but there are others. One thing I would suggest is possibly having a SHOULD/MAY for UMA. There would be a MUST for using the WWW-Authenticate for informing the clients how to discover the AS. The `as_uri` is how UMA and GNAP does this, so maybe a SHOULD for this parameter. * EP: I can see UMA being a SHOULD/MAY for the FPWD. We should have a MUST for interoperability, while keeping a SHOULD were applicable for flexibility. * AC: We should add a note to the spec explicitly mentioning that the role of UMA is being evaluated. Suggestion: UMA is mentioned as a SHOULD in the FWPD * +1 EP * +1 AC * +1 NAS * AC: Are there additional questions on this PR beyond what has been discussed so far? * TH: Not yet, we'll have to work on it more to be able to have an opinion * AC: This is just for a FPWD anyway, there will be more opportunities to discuss this in the future * EP: The motivation for this change is to reduce the scope of the access token so that it isn't global to the whole ecosystem. The proposed approach would also enable data grants (as defined by the interop panel) to be pushed to extend the access token. This creates a clean, specified extension point for the AuthZ-related claims. ### Organize sections by conformance classes * EP: Feel free to comment in the proposed list of conformance classes ([related issue](https://github.com/solid/solid-oidc/issues/65)). After PR#18 is merged, I'll work on a different PR to shuffle sections around to move closer to the conformance class organization. There will be cases where a given feature will have different requirements for different conformance classes. This will make it easier as an implementor to see what one should implement to create a spec-conformant piece of software. * AC: This reorganization will make the test suite easier to implement. * EP: There are 6 conformance classes, do we agree on the proposed list ? * End User's WebID Document * OpenID Provider (OP) * Client's ID Document * Client * Resource Server (RS) * Authorization Server (AS) * AC: This list looks pretty comprehensive at the moment. * EP: It will take me about a week on a new PR to reorganize the requirements.