From ad1b17c740c7d1821f188d61379143369a367e84 Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Wed, 18 Feb 2026 09:32:56 -0600 Subject: [PATCH 1/2] Create 2026-02-18.md --- meetings/2026-02-18.md | 158 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 158 insertions(+) create mode 100644 meetings/2026-02-18.md diff --git a/meetings/2026-02-18.md b/meetings/2026-02-18.md new file mode 100644 index 00000000..a7a9edf9 --- /dev/null +++ b/meetings/2026-02-18.md @@ -0,0 +1,158 @@ +# W3C Solid Community Group: Weekly + +* Date: 2026-02-18T14:00:00Z +* Call: https://meet.jit.si/solid-cg +* Repository: https://github.com/solid/specification + +## Chair + +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) + +## Present + +* Theo [@thhck](https://github.com/thhck) +* [Luke Dary](https://w3c.social/@lukedary) +* Sarven Capadisli +* [Michal](https://id.mrkvon.org) +* [Jesse Wright](https://www.jeswr.org/#me) +* Alain Bourgeois +* Christoph Braun — [uvdsl](https://github.com/uvdsl) +* [Jacqueline Boltik](https://github.com/jboltik) +* Andrealiz +* [Ted Thibodeau Jr](https://www.linkedin.com/in/macted/) (he/him) (OpenLinkSw.com) // GitHub:[@TallTed](https://github.com/TallTed) // Mastodon:[@TallTed](https://mastodon.social/@TallTed) + + +## Regrets + +* + +## Scribes + +* Sarven Capadisli + +--- + +## Announcements + +### Meeting Guidelines + +* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). +* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). +* 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. +* Join queue to talk. +* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed. + +### 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/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Conduct](https://www.w3.org/policies/code-of-conduct/) +* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. +* If this is your first time, welcome! Please introduce yourself. + +--- + + + +## Introductions + +* RB: I've just joined ODI as Community Manager. Am Brazilian. Coming from Inrupt. Excited to get started and see what it is I can do to help here. Looking at this from two sides. Portal to ODI and coordinate with rest of Solid team at ODI. +* eP: Do you also help coordinate the SoSy 2026 endevaour? +* RB: I'll help with specifics on ODI's connection to the Symposium +* JW: *shares screen on Solid Barriers to Adoption* . RB will help collect UCs and communication to help as a middle-person with the CG with persona adoption. +* eP: One of my concerns is that we haven't really created a TODO list. What is the cut off for example. We said for three months before SoSy. I'm a bit concerned we have this timeline but I can't say how we track progress or accomplish by then. +* JW: Ack. Will take responsibility on that and help out in the next weeks. +* JW: https://docs.google.com/spreadsheets/d/1F0_TRi3p2caS5oaktYjvnZy5jbElenkIBMkXNA3MCME/edit?gid=0#gid=0 — re Access Control and Solid 1.0 items — standards gaps items — that covers a lot of the details I have in mind. Don't care which but we could aim to "pick" one Access Control by SoSy. Aware that CB and SC are looking into enhancing WAC. Other things include: best practices on storing VCs, provenance and usage controls. How to point to ODRL auxiliary resource etc. +* eP: Didn't mean to push blame. Wanted to see what we can realistically do. Re WAC vs. ACP, I somewhat agree with CB, maybe we can't decide on one, but lets see. For me it is important on implementations. Solid ODI uses CSS and ESS. I don't know if ESS can do WAC. That would be one of the questions for me. If those could conform to one, ???. And who is participating. There is no one in Inrupt from the CG — at least for two years. I think it'd be useful to say that ESS is one of the implementations but without participation, it'd be hard to say / expect anything. +* JW: LWS chairs have visibility and Inrupt folks as well are aware of this. They won't be in the calls but will tag as needed. +* eP: For other implementations, Ben ??? has a server representation. Are there other implementations that could provide input? +* JW: Good shot for us to contact Ben and Fredrick. RB could take an action on this? +* SC: It's been unclear to me, expectations or work that ODI is doing and how that drives these epics and what is expected from CG to do. This is first time I see this document "Solid Barriers to Adoption". There are folks from various orgs that were aware and provided input. What is expected from CG to follow those plans. +* JW: re context of this document, Oli Bage worked at x,y,z, and had contract with ??? to promote Solid. Open Source developer kind of person. They are coming as a strategic advisor. [CDMC](https://edmcouncil.org/frameworks/cdmc/) sets on how to deploy cloud tech in the industry. He has experience in adoption of especially in enterprise space. These barriers of adoption are coming from there. Solid 2026 is largely a marketing campaign — but don't want to create much work for the CG. Putting material to demo, training, etc. for non-tech people in the ??? centre. The items related to CG, e.g., script authentication. ODI can do most of the work here. But we don't want to be authoritative to contribute to the spec. +* SC: The authority, governance between different parties is not entirely clear to me. This is a CG call, we operate with expectations of CG / W3C. When it comes to broader Solid Project as a whole more needs to be taken into account. There is idea of CSS and ESS being input to what spec should be. I have concerns, it's not just ESS but also CSS. Implementers in both areas... have not been making commitments to some specifications, there were releases of various specs and we haven't received feedback/input. We know that there were security issues and some of that information didn't make it's away back to the CG. There is an information gap and held back. There is something missing here and I don't feel quite comfortable ... CSS emerged from Inrput, this is the same board room. Also ODI has various individual currently or formerly from Inrupt. When you put your CG participant hat on, where do you bring o leave other hats. Where do you prioritize needs of CG and how you separate it from needs of your organization. There is some solution/idea being presented but there is a question should we entertain ??? . It should come weather if we should be evaluating it as CG. Parts that are relevant to CG are made by parties that are not parts of the CG. We had WAC for example, and Inrupt proposed ACP as the thing. We made release within CG, we forced that in with Tim's blessing. In 4 years now there has been no updates to that spec of any significant activity in the repo, or implementation feedback. It is hard to take ACP as legitimate thing. ACP has been in production for 4-5 years in enterprise space, it accumulated that knowledge and haven't shared single line of implementation feedback. Why CG should entertain it? Put more value/weight in what they think CG should be doing. +* JW: This set of requirements has been put together by Oli and I. It was presented to LWS WG. I want to be clear that in none of those conversations those parties given input to that document, at least not in a way that you may be worried about. +* eP: Thanks both. Let's continue later. + + +## Topics + +### Solid World +https://www.w3.org/events/meetings/07b8e462-dc84-458d-a8f1-0af1bc9619a6/ + +* eP: Starts an hour after this call. + + +### Solid-ODI Community Manager +https://matrix.to/#/!LCtvHcfpDwWNfvmsEd:matrix.org/$yAjjsrQB0eLmAv6AxJNQW40DVgXIkKJPXjPxqAHnwag?via=matrix.org&via=gitter.im&via=chat.semantic.works + +* eP: in case Roberto joins we can discuss what and how we'll be coordinating + + + + +### Actions Review + +* At weekly meeting on 2026-02-25, CB to present https://github.com/uvdsl/solid-authorization-app +* eP to follow up in mailing list about scheduling poll +* JW to share first draft of `diff LWS Solid` Note +* JW to share notes on Fediverse with everyone + + +### Pull requests + +#### feat: add client credentials as a MUST +https://github.com/solid/solid-oidc/pull/245 + +* CB: Which alternatives were evaluated? +* CB: AC also raised the same. Whether client credential is good / best way. +* JW: I wanted to take what CSS and ESS already do. I'm not aware of what GraphMatrix or PDSInterop does. This is not something that I expect to be ??? for April really. Giving people a way to login re script-based authentication. So, haven't evaluated other methods. +* eP: Since we talk about implementations. Familiar with CSS, one to allow with URLs. Dynamic registration is optional. Static has some issues. This approach where client can only register one. I created this https://github.com/solid/solid-oidc/pull/245 but there wasn't much interest then. Who from ESS would represent? AC gave some pushback. Anyone else from ESS would like to represent? I'd like to understand re implementations. +* CB: Does this include that the client advertises the key pair in the client metadata document? +* eP: There is the grant flow and client authentication with endpoint. Client does with asym keys (?) Opaque credentials. This assertion is used instead of client credentials. The assertion is provided. Zero feedback so far but.. +* CB: Re zero feedback, this is how the CSS crew operates, they are rather opposed to implementing things that are not in-spec... +* SC: CSS implemented and has documentation for things that are not in specs. I'm not refuting what you said. As general comment, not about ESS/CSS strictly. We can't wait around and wait to see whether implemented who has history of not engaging with CG to provide feedback. We don't see any applications that are even visible to the CG. To wait around and make decisions to make sure that specific implementer is happy may not be the best strategy for the CG. Activity is good, if we can form/shape specs and act on actual incubated stuff. IF ESS/CSS are not particularly engaged, there is GraphMetrix and NSS which I use myself. There are other implementations, why we don't put equal energy to get those implementers input and have them weigh in on the equal grounds. We need to "fix the web" (as Tim says sometimes as well). There are a lot of adoption question and implementations which focus on subset / somewhere else. Maybe their should start a new CG. +* JW: This is not about pushing a particular implementor. ODI is implementor agnostic. the PR here is trying to look realistically to get some script authentication for April. I'm all for implementing other things. The point is not to have fully finished thing for advertising. It is to say to different orgs, people, academia, that have looked at and got turned away or thought it was too early. And we want to iterate specs based on that feedback. Through different personas. +* eP: I'd like to invite CB as co-editor of Solid-OIDC. It is obvious that this is not ??? long-time solution. There is a bit of a disconnect on how they see the topic. They may keep LWS work in mind when discussing it. +* CB: I prefer complete ??? specs instead of opening 5 tabs. Preference to include a section on client/server authentication. I can support the idea that to document the status-quo or current state of how it is done — I think that is a good idea, or at least put a Note on how it currently works. I'm hesitant to simply accept the feedback from AC or LB as given truth. While it is possible to use refresh token, there is zero info in the spec on how to do it. Just because AC is doing it — and I know how AC is doing it — because some people are able to do it it isn't worth documenting or having alternative solutions. So, I'd +1 on the PR. +* eP: What I find challenging with roadmap to Solid ??? we don't have to worry about how to separate things. I'm missing the part on how we adopt from LWS or ??? I'm a bit lost. +* CB: Compatibility with LWS, it is not as opinionated as one might think. Gives a general framework but no specifics. Solid-OIDC is still the implementable spec. Assuming that LWS will define OIDC based protocol. Because everything I said is purely speculative, there is no ground to operate on. +* eP: DO you mean Solid-OIDC implemented in CSS with ??? or ??? +* CB: When you look at CSS, ??? ... meaning CSS is also doing a hack. In the end, I ended up having the same token for id and access. Not nice but works. There is still plumbing to do on Solid-OIDC to figure details out. At least details to be explained. I think this is something I can take on as part of contributing. +* eP: Perhaps next week we can have a special topic on this. +* CB: I'm at capacity. So, can't prepare anything. If you know there'll be much attention, you can try that. Otherwise, I'd defer that since it is not a pressing thing in my mind — perhaps at or after SoSy. +* eP: solidcommunity.net is not doing Solid-OIDC-??? +* JW: Best to do separate client credentials or? +* CB: My suggestion is to get more feedback. +* SC: More of a general strategy, not about technicalities. To answer your question about separate spec or self contained. Maybe we can do threat modeling. To get a sense of weather, what happens in Solid-OIDC without those changes. Does it belong there, is it extension, separate capability. + + +#### Add Support for Client Identification and Issuer Identification +https://github.com/solid/web-access-control-spec/pull/133 + +* eP: is single active editor for WAC enough? +* eP: ACP has zero active editors ATM! +* CB: Enough for what? +* SC: I am actively editing WAC and will continue to do so. Neither editorial count nor surface level "activity" alone determines whether work can advance. If there are defined requirements for advancement in the Solid 2026 planning, please reference them so we can align accordingly. +* CB: In Solid-OIDC in particular, there is the notion of the client and the issuer (provides identity to the user). There are use cases where either one may need to be restricted. Of course this has been long debated. Corresponding issue is from 2021 and there is history also resulting partially in ACP. This PR was opened as a draft and remains a draft. We have a good amount of discussion on this topic. +* eP: From the implementation perspective https://sai.js.org , I'm using ACP, because I need client restrictions, also I have registries. If I wanted to I can't use WAC right now. +* CB: We also had that discussion about restricting clients in MANDAT project — it was for research / abstracted away, but still relevant. +* CB: WAC has historically been based on a documentation of what was there. It is traditionally generic. Don't mean that in a bad way. Generic as in "not specific". Transitioned well from WebID-TLS to Solid-OIDC and it'd be applicable to many authentication mechanisms. SC pointed out that it shouldn't be tailored to one solution and work alongside other authentication models. I've been thinking about how restrictions on client/issuer where generic view of access control. What I found out a few hours ago — doing a bit of research on NIST digital identity management, and also Microsoft Entra, on how they do restrictions or do access. We can look at this for inspiration or general model. The "subject" in there — same as in WAC — is only the "agent" which may be tied to an identity provider but it is not the first-class citizen or same-level. It is not a tuple as was in my initial design — in my original version the agent being split between agent and client. NIST was saying there is some environment or constraint that's applied here. +* eP: When you talk about this tuple from the delegation point of view. We can also look at how user delegates rights and delegation chain. There is an aspect of who delegated. I don't know for WAC but it is a useful way of thinking about it. +* CB: That delegation part is one that can be faciliated with a constraint rule. In WAC or WAC-next, this is a rule, and certain constraints apply, e.g., time-based constraint. This rule is only valid until yyyy. Somebody with a certain attribute. Or this rule specifies that someone delegates to someone and it applies. The general model that I'm settling on is a constraint model, which is introduced to core WAC rather than extending it. +* eP: If you are the creator of the resource, you have an extra mode. +* SC: We can agree that there are infinite variables that can be taken into account for different use cases and say that this is how authorization should work. I think WAC shouldn't try to solve all that, anything from age based restrictions to other examples, whatever they may be. Where does the client and issuer fit into that picture. Time based is very useful. Should WAC be solving it, we have things like ODRL where we can hook a lot of stuff to. It is useful and important to have if WAC is coupled with authenticastion models that include that information. I would like to see that happen and this PR is important to solve that model. I know that we don't do WebID-TLS. WAC was able to survive all this time because it is simple. It is largely what most people on the web do. If we casn present user interface that is wrapped around idea of viewing/editing etc. Even that can be a challenge for less technical people. Most of the web doesn't opperate on the level where you have a lot of complexities, it depends on the environment. Where do we draw lines and say these are futures. How server signals that it has certain capabilities. ... set of capabilities that with certain information authorization rule can be enforced. I would like to see this PR to move. The other one is about implementations. What happens to the existing implementations, what happens to the existing ACLs, how serveers handle new features, what the clients do. Some formal WAC implementations, even W3C uses WAC for some resources. I can't speak for W3C as implementer, I don't think they will introduce client and issuer. Getting clients (at least) into WAC, it would have to do with complexity it introduces. We didn't want to take the same route as ACP. Don't force feature in without implementations which will be commiting to it. ACP happened for political reasons, it is a question mark on how secure it is. People wanted it but do they actually implement it. Let's get it in while minimising the disruption. We may need a future detection, is it save? Or let' say we break it and let's go and fix implementations and existing ACL resources, for example by default add ... We have done it in the past in solidcommunity we run a migration script to update data. Upgrade your implementation of WAC to understand clients and classes of clients. +* CB: I think your concerns are valid. One thing is about the model and concerns on backwards-compatibility. The other is enabling a legacy and new implementations. How they talk to one another should be clear. I tihnk the mandate should be on "please include this new stuff". And ther other what you pitched in the PR, if you (client) don't see the feature available then assume the old. If people want to port the old to new rules for implementation. Then we have the problem of conflating - may need a new class to not mix constraints so they are not ignored. How exactly that plays out in ontology design etc happy to discuss. + +MEETING ENDS +---------- + +#### Support for RFC 9207 (Authorization Response Issuer Identification) +https://github.com/solid/solid-oidc/pull/243 + +* eP: I already suggested that Christoph could join as Solid-OIDC co-editor +* CB: I am willing to co-edit :slightly_smiling_face: + +### 2026 CG Roadmap (15+ min) +* CB: https://github.com/w3c-cg/solid/issues/54 + + +## Actions + From faecb473e49840623ed44ba4097338f088b7eb80 Mon Sep 17 00:00:00 2001 From: elf Pavlik Date: Wed, 18 Feb 2026 11:12:04 -0600 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Christoph Braun --- meetings/2026-02-18.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/meetings/2026-02-18.md b/meetings/2026-02-18.md index a7a9edf9..0ea80a5e 100644 --- a/meetings/2026-02-18.md +++ b/meetings/2026-02-18.md @@ -111,14 +111,14 @@ https://github.com/solid/solid-oidc/pull/245 * SC: CSS implemented and has documentation for things that are not in specs. I'm not refuting what you said. As general comment, not about ESS/CSS strictly. We can't wait around and wait to see whether implemented who has history of not engaging with CG to provide feedback. We don't see any applications that are even visible to the CG. To wait around and make decisions to make sure that specific implementer is happy may not be the best strategy for the CG. Activity is good, if we can form/shape specs and act on actual incubated stuff. IF ESS/CSS are not particularly engaged, there is GraphMetrix and NSS which I use myself. There are other implementations, why we don't put equal energy to get those implementers input and have them weigh in on the equal grounds. We need to "fix the web" (as Tim says sometimes as well). There are a lot of adoption question and implementations which focus on subset / somewhere else. Maybe their should start a new CG. * JW: This is not about pushing a particular implementor. ODI is implementor agnostic. the PR here is trying to look realistically to get some script authentication for April. I'm all for implementing other things. The point is not to have fully finished thing for advertising. It is to say to different orgs, people, academia, that have looked at and got turned away or thought it was too early. And we want to iterate specs based on that feedback. Through different personas. * eP: I'd like to invite CB as co-editor of Solid-OIDC. It is obvious that this is not ??? long-time solution. There is a bit of a disconnect on how they see the topic. They may keep LWS work in mind when discussing it. -* CB: I prefer complete ??? specs instead of opening 5 tabs. Preference to include a section on client/server authentication. I can support the idea that to document the status-quo or current state of how it is done — I think that is a good idea, or at least put a Note on how it currently works. I'm hesitant to simply accept the feedback from AC or LB as given truth. While it is possible to use refresh token, there is zero info in the spec on how to do it. Just because AC is doing it — and I know how AC is doing it — because some people are able to do it it isn't worth documenting or having alternative solutions. So, I'd +1 on the PR. -* eP: What I find challenging with roadmap to Solid ??? we don't have to worry about how to separate things. I'm missing the part on how we adopt from LWS or ??? I'm a bit lost. +* CB: I prefer tightly coupled and uniform specs instead of opening 5 tabs to read through fragmented specifications. Preference to include a section on client/server authentication. I can support the idea that to document the status-quo or current state of how it is done — I think that is a good idea, or at least put a Note on how it currently works. I'm hesitant to simply accept the feedback from AC or LB as given truth. While it is possible to use refresh token, there is zero info in the spec on how to do it. Just because AC is doing it — and I assume I know how one could do it — but just because some people are able to do it does not mean it isn't worth documenting or having alternative solutions. So, I'd +1 on the PR. +* eP: What I find challenging with roadmap to Solid 2026 we don't have to worry about how to separate things. I'm missing the part on how we adopt from LWS or ??? I'm a bit lost. * CB: Compatibility with LWS, it is not as opinionated as one might think. Gives a general framework but no specifics. Solid-OIDC is still the implementable spec. Assuming that LWS will define OIDC based protocol. Because everything I said is purely speculative, there is no ground to operate on. * eP: DO you mean Solid-OIDC implemented in CSS with ??? or ??? -* CB: When you look at CSS, ??? ... meaning CSS is also doing a hack. In the end, I ended up having the same token for id and access. Not nice but works. There is still plumbing to do on Solid-OIDC to figure details out. At least details to be explained. I think this is something I can take on as part of contributing. +* CB: When you look at CSS, you'll see that CSS is also doing a hack. One, I also reverted to for my toy IdP. In the end, I ended up having the same token for id and access. Not nice but works. There is still plumbing to do on Solid-OIDC to figure details out. At least details to be explained. I think this is something I can take on as part of contributing. * eP: Perhaps next week we can have a special topic on this. * CB: I'm at capacity. So, can't prepare anything. If you know there'll be much attention, you can try that. Otherwise, I'd defer that since it is not a pressing thing in my mind — perhaps at or after SoSy. -* eP: solidcommunity.net is not doing Solid-OIDC-??? +* eP: solidcommunity.net is not doing Solid-OIDC UMA? * JW: Best to do separate client credentials or? * CB: My suggestion is to get more feedback. * SC: More of a general strategy, not about technicalities. To answer your question about separate spec or self contained. Maybe we can do threat modeling. To get a sense of weather, what happens in Solid-OIDC without those changes. Does it belong there, is it extension, separate capability. @@ -134,12 +134,12 @@ https://github.com/solid/web-access-control-spec/pull/133 * CB: In Solid-OIDC in particular, there is the notion of the client and the issuer (provides identity to the user). There are use cases where either one may need to be restricted. Of course this has been long debated. Corresponding issue is from 2021 and there is history also resulting partially in ACP. This PR was opened as a draft and remains a draft. We have a good amount of discussion on this topic. * eP: From the implementation perspective https://sai.js.org , I'm using ACP, because I need client restrictions, also I have registries. If I wanted to I can't use WAC right now. * CB: We also had that discussion about restricting clients in MANDAT project — it was for research / abstracted away, but still relevant. -* CB: WAC has historically been based on a documentation of what was there. It is traditionally generic. Don't mean that in a bad way. Generic as in "not specific". Transitioned well from WebID-TLS to Solid-OIDC and it'd be applicable to many authentication mechanisms. SC pointed out that it shouldn't be tailored to one solution and work alongside other authentication models. I've been thinking about how restrictions on client/issuer where generic view of access control. What I found out a few hours ago — doing a bit of research on NIST digital identity management, and also Microsoft Entra, on how they do restrictions or do access. We can look at this for inspiration or general model. The "subject" in there — same as in WAC — is only the "agent" which may be tied to an identity provider but it is not the first-class citizen or same-level. It is not a tuple as was in my initial design — in my original version the agent being split between agent and client. NIST was saying there is some environment or constraint that's applied here. +* CB: WAC has historically been based on a documentation of what was there. It is traditionally generic. Don't mean that in a bad way. Generic as in "not specific". Transitioned well from WebID-TLS to Solid-OIDC and it'd be applicable to many authentication mechanisms. SC pointed out that it shouldn't be tailored to one solution and work alongside other authentication models. I've been thinking about how restrictions on client/issuer where generic view of access control. What I found out a few hours ago — doing a bit of research on NIST digital identity management, and also Microsoft Entra, on how they do restrictions or do access. We can look at this for inspiration or general model. The "subject" in there — same as in WAC — is only the "agent" which may be tied to an identity provider but the IdP is not a first-class citizen or same-level. The subject is not a tuple as was in my initial design — in my original version the agent being split between agent and client. NIST was saying there is some environment or constraint that's applied here. * eP: When you talk about this tuple from the delegation point of view. We can also look at how user delegates rights and delegation chain. There is an aspect of who delegated. I don't know for WAC but it is a useful way of thinking about it. * CB: That delegation part is one that can be faciliated with a constraint rule. In WAC or WAC-next, this is a rule, and certain constraints apply, e.g., time-based constraint. This rule is only valid until yyyy. Somebody with a certain attribute. Or this rule specifies that someone delegates to someone and it applies. The general model that I'm settling on is a constraint model, which is introduced to core WAC rather than extending it. * eP: If you are the creator of the resource, you have an extra mode. * SC: We can agree that there are infinite variables that can be taken into account for different use cases and say that this is how authorization should work. I think WAC shouldn't try to solve all that, anything from age based restrictions to other examples, whatever they may be. Where does the client and issuer fit into that picture. Time based is very useful. Should WAC be solving it, we have things like ODRL where we can hook a lot of stuff to. It is useful and important to have if WAC is coupled with authenticastion models that include that information. I would like to see that happen and this PR is important to solve that model. I know that we don't do WebID-TLS. WAC was able to survive all this time because it is simple. It is largely what most people on the web do. If we casn present user interface that is wrapped around idea of viewing/editing etc. Even that can be a challenge for less technical people. Most of the web doesn't opperate on the level where you have a lot of complexities, it depends on the environment. Where do we draw lines and say these are futures. How server signals that it has certain capabilities. ... set of capabilities that with certain information authorization rule can be enforced. I would like to see this PR to move. The other one is about implementations. What happens to the existing implementations, what happens to the existing ACLs, how serveers handle new features, what the clients do. Some formal WAC implementations, even W3C uses WAC for some resources. I can't speak for W3C as implementer, I don't think they will introduce client and issuer. Getting clients (at least) into WAC, it would have to do with complexity it introduces. We didn't want to take the same route as ACP. Don't force feature in without implementations which will be commiting to it. ACP happened for political reasons, it is a question mark on how secure it is. People wanted it but do they actually implement it. Let's get it in while minimising the disruption. We may need a future detection, is it save? Or let' say we break it and let's go and fix implementations and existing ACL resources, for example by default add ... We have done it in the past in solidcommunity we run a migration script to update data. Upgrade your implementation of WAC to understand clients and classes of clients. -* CB: I think your concerns are valid. One thing is about the model and concerns on backwards-compatibility. The other is enabling a legacy and new implementations. How they talk to one another should be clear. I tihnk the mandate should be on "please include this new stuff". And ther other what you pitched in the PR, if you (client) don't see the feature available then assume the old. If people want to port the old to new rules for implementation. Then we have the problem of conflating - may need a new class to not mix constraints so they are not ignored. How exactly that plays out in ontology design etc happy to discuss. +* CB: I think your concerns are valid. One thing is about the model and concerns on backwards-compatibility. The other is enabling a legacy and new implementations. How they talk to one another should be clear. I tihnk the mandate should be on "please include this new stuff". And other what you pitched in the PR, if you (client) don't see the feature available then assume the "old" WAC being implemented. If people want to port the old to new rules for implementation. Then we have the problem of conflating - may need a new class to not mix constraints so they are not ignored. How exactly that plays out in ontology design etc happy to discuss. MEETING ENDS ----------