# W3C Solid Community Group: Weekly

* Date: 2023-05-31T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* Maxime Lecoq
* elf Pavlik
* Tim Berners-Lee
* michal/mrkvon

---

## 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/solid/specification/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 Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* 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.

### Scribes
* Sarven

### Introductions
* name: text

---

## Topics

### W3C TPAC 2023
URL: https://www.w3.org/2023/09/TPAC/

* SC: Will anyone be in person at TPAC 2023?
* PA: I should be.
* SC: Solid CG will have a meeting as part of TPAC's Group events.
* SC: WIP [TPAC 2023 - Group schedule](https://docs.google.com/spreadsheets/d/1Tj66Ase5tc--S-Vjo9Q1pXEINaTmOEzDpnS1J5gtqOI) is posted. Solid CG is on row 70 in the spreadsheet.
* SC: Solid CG meeting is on 2023-09-11 (Monday), available time slots: 12:30-14:30 UTC and 15:00-16:30 UTC.
* SC: Any preference on the slot?
* PAC: Hope that we have a WG at that point. Should we consider that CG meeting with WG meeting? At this point there's nobody to manage the WG meeting. Would that be acceptable for the CG? I think we should plan enough time for WG specific matters.
* SC: WebAgents may possibly out of scope or relatively new for the WG. Also not sure if it is good use of WG's time for a joint meeting. That said meeting can happen any time. Perhaps better fitting for the CG since it is more incubation space.
* PAC: Agree.
* SC: If use the 2h slot (12:30-14:30 UTC), we can incorporate a joint meeting with the [Autonomous Agents on the Web CG](https://beta.w3.org/groups/cg/webagents/) whom has shown interest to have a joint meeting with us.
* PAC: The exchanges that I had with Andrei / Chair of WebAgents CG, talked about Solid and how they are related. It is worth discussing with them, not necessarily for the whole time. This is an interesting community to have a fresh look at what we're doing in Solid.
* SC: We can have the meeting any time..

### WIP Implementation Feedback
* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
* eP: Pretty much done with non-RDF Sources for SAI. I can demo things for next week - max 10 minutes. I plan to document some things / having createUI object in Javascript. Authenticated requested. Need to use authenticated fetch. I'll probably add it to SAI Primer. Not sure if there is a better place for it. MDN has a JS like guides. I want to add something to SAI Primer to document this kind of tips if someone implements that, e.g., hidden input, anchor, download attributes, get the attributes from ??? I'll have it ready for next week.
* eP: For today, we are saving filename and mime type in resource description
* https://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html#type
* https://www.semanticdesktop.org/ontologies/2007/03/22/nfo/#fileName
* eP: Not much mime type predicates in LOV.
* eP: The mime-type of the representation.
* SC: `http://www.w3.org/ns/iana/media-types/{mimetype}#Resource` I think.
* TBL: Yes. That is what CSS and NSS do with a folder .

    dc:modified "2020-05-07T21:05:57.000Z"^^xsd:dateTime.
   <> posix:mtime 1588885557;
``
* eP: To clarify it is the resource that links to mimetype.
* TBL: Another way: w3c has RDF copy of IANA data.
* eP: I don't see a problem with string literals but what's recommended predicate to relate a resource (like an image) to it's mime-type (content-type). 
  * eP: I get mime type of file that will get uploaded using browser interface which returns plain string like `image/png` or `text/calendar` https://developer.mozilla.org/en-US/docs/Web/API/File/type
* eP: an [example](https://github.com/janeirodigital/sai-impl-service/pull/86/files#diff-8b1be0bca53bf3783b0a57ae153a399d57fb75fbcf9852608c548003a3b01263) of Resource Description for an image
* ML: Solid indexer is an agent that indexes some resources on a Pod in an autonomous manner. I did present it at Solid MCR (Manchester Solid Community). Went nice. Had some tech issues but people were interested. Planned a meeting with JesseW to discuss about client-to-client specs and Solid tools for developers.
    * https://github.com/Wimmics/solid-indexer


### Fix representation of Solid Notifications Protocol JSON-LD context
URL: https://github.com/solid/vocab/issues/88#issuecomment-1566884931

* SC: For W3C Team (TimBL, PAC). Mentioning here for awareness.
* SC: We need this: https://raw.githubusercontent.com/solid/vocab/main/solid-notifications-context.jsonld instead of https://github.com/solid/vocab/blob/main/solid-notifications-context.jsonld

ACTION: PAC to follow-up.


### Compatibility with existing implementations
URL: https://github.com/solid/solid-wg-charter/issues/31

* TBL: Solid Protocol is a high-level, robust specification. Hopefully it'll be in 1.0 in WG. Interop spec has nothing to do with it. It doesn't have CG consensus. Can't criticise for some party. I'd not encourage the Interop spec. A lot of people have issues with it. Inteorp spec doesn't have consensus. We have interoperable chat / but they are at the early stages. So client-client specs like Interop spec.. we should make it clear that does not have CG consensus. Can't criticise for not implementing.
* eP: Just want to add Tom's concern. Interop doesn't have consensus in the CG but there has been work in the CG and went through open process. I think tom is pointing to Inrupt is doing own thing that wasn't brought to CG> If there is changes that's not part of CG process,.. it is internal company.
* TBL: That's not what he is saying. The Interop spec is complex and any person to create an application would be / is? constantly running ??? which is not the Solid Protocol.
* TBL: Agree with SC's comment on Solid Protocol's relevancy.
* eP: I think we should ping Tom. Noticed that ESS link is about access request grants / actually about authorization. SAI also covers a bit. In https://github.com/solid/specification/issues/517 I tried to cover the general topic. Interop covers that.. There are possibility ot reconcile but it is very authorization related. I htink Interop and Inrupt can be reconciled.
* TBL: I think the text is important because for people joining the WG that haven't been involved in the CG before point out to them that this Protocol has been running for years. Gently being modified and improvement. Large changes wouldn't be appropriate. As you said ??? for interoperable implementations. The stability of that is important for the whole ecosystem.
* eP: It'd help to clarify implementation conforming to what? Implementation conforming to which version. Which version being submitted to the WG. In those implementations doing custom stuff, it wouldn't be covered. Anything not in the Solid Protocol won't be taken into account. Experiments.
* SC: I'd recommend the WG to take the latest Editor's Draft because the changes have received consensus.
* PAC: Also my position.


### Scope needs to be tightly defined with narrow focus
URL: https://github.com/solid/solid-wg-charter/issues/9

* SC: Any objection to removing OIDC-related item from scope?
* PAC: Not sure how mature enough but OIDC is current widespread way of doing it with Solid. Although I appreciate this can be questioned. It seems the WG should work on things incubated enough.
* SC: Would other authentication mechanisms be in scope?
* eP: I'll say as co-editor of Solid OIDC as someone implemented in-browser and server-side, the issue 504, Solid OIDC is great on device clients but not really well for server-side clients. As we are adjusting this issue we should open for server-side clients but fit for something other than Solid OIDC.
* TBL: It has moved steadedly. Stability of the Solid OIDC is important. If we think of moving from Solid OIDC like HTTPSignatures where you have public keys.. like we had with WebID-TLS would be a lot simpler and lot more powerful and secure. So I think if we move, it is worth considering moving to two where we experiement with completely different public-key based rather than HTTP redirect based.
* TBL: Reasonable to keep the WG focused. I think in the CG we should look at alternatives which in the end might be better.
* eP: I'm just saying that Solid OIDC is fit for some things.. When we talk about server-side clients the scneario is different where keys can be rotated. As long as aligned for authorization servers. It is not just limiting to Solid OIDC. It is on client devices.. 
* eP: We can't just Solid OIDC because of OIDC. Constraints for device clients with Web applications .. possibly as much as possible for what Solid OIDC does but not OIDC based what can be used for server-side clients.
* SC: PROPOSAL to allow other authentication mechanism in scope since it does not entail it will be a work item for the WG.
* PAC: Seems reasonable.
* eP: If something is not in scope but out of scope, what other things explicitly.. HttpSig is not listed as out of scope. 
* eP: I'd lean on removing OIDC from Scope. They are already in Deliverables more or less. The Scope could be more abstract re authentication.
* PAC: This abstract point is second point in the list for practises for data security... would HTTPSig fit there? That's obviously variant of that generic point but it should be explictly in the scope.

ACTION: SC to PR suggestions from all..


### Strategy for normative references
URL: https://github.com/solid/solid-wg-charter/issues/37


### Update mission
URL: https://github.com/solid/solid-wg-charter/issues/7