# W3C Solid Community Group: Weekly

* Date: 2022-11-16T14: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)
* Jeff Waters
* elf Pavlik
* Arthur Joppart
* Tom Haegemans (https://digita.ai)
* [Henry Story](https://mathstodon.xyz/@bblfish)
* [Eric Jahn](https://alexandriaconsulting.com/files/eric_jahn.rdf#me)
* [Dan Bakas](https://id.inrupt.com/danielbakas)
* Stijn Taelemans (https://digita.ai)
* Maxime Lecoq
* Wouter Termont
* [Matthias Evering(ewingson)](https://solidweb.me/testpro/)
---

## 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.
* Join queue 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/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
* Dan
* Virginia
* Jeffrey

### Introductions
* EJ: Have attended meetings already. Work at BitFocus as interoperability ??? Open source project looking to collaborate.

---

## Topics

* SC: Today's topics are intended for awareness and build engagement as opposed to solving technical details here.

### Agenda and Minutes

* SC: Agenda is typically PRd at https://github.com/solid/specification/
* SC: Reviews on the PR are welcome.
* SC: Previous meeting's minutes are at https://github.com/solid/specification/blob/main/meetings/2022-11-09.md and you can always find prior minutes at https://github.com/solid/specification/blob/main/meetings/.
* SC: Please note that unless there is a decision to change the meeting datetime, it is always on UTC time (and daylight savings time is not observed, as it stands).

* SC: Please speak clearly and slowly to help with transcribing.
* SC: Editorial help with transcription is welcome, e.g., where scribe marks `???`, adding links, fixing grammar, or typos. However, do not change or elaborate on earlier transcription, especially what was not explicitly "aired" by the group.

### Add PB profile shape for discussion
URL: https://github.com/solid/webid-profile/pull/79

* SC: VB will describe.
* VB: This PR adds the ShEx shape used in PodBrowser to kick off the discussion (although we will use SHACL, this is just to have a starting point). Comments are welcome.
* SC: Solid WebID Profile spec is trying to work its data model. With that we need to look at the cardinalities. A couple of issues linked to the PR as some topics have been already been discussed. The SHACL shape will eventually be one way of communicating the cardinality that the spec will describe.
* SC: https://github.com/solid/webid-profile/issues/26
* SC: Planning to process each rule?
* VB: If anything stands out, great to have comments.
* EP: With respect to https://github.com/solid/webid-profile/pull/79/files#diff-2c97825c8bb9e1c6cdb6092b5daaef1639bf9013e52e8d05f2c1fd4a7798f335R119 is anyone working on trusted app draft? As that was just in old WAC draft.
* VB: It is being taken into consideration. I am working on it at the moment.
* SC: Related: https://github.com/solid/vocab/issues/64
* VB: Better to discuss trusted app in particular when we have a draft/proposal.
* VB: There is also: https://github.com/solid/webid-profile/issues/16
* WT: Solid Profile shape is a person that has all the attributes, the current practice is we have a profile document that refers to a person, which then has the attributes. The convention currently is in a WebID Profile there's a statement that says "this doc is a profile, and the primary topic is a person", and then all the attributes are predicated of the person; whereas this Solid-PROFILE-Shape immediately considers a subject that is a person and has all the attributes.
* SC: I think you raise something important and whether either one of those is required is part of this exercise of what that shape will look like. The general expectation is describing the WebID "thing" and the part about the primary topic of the personal profile doc is a glue that's added if you're describing a WebID.
* WT: I don't think that it's necessary, but I would rename the shape to make it clear it is a person, not a profile.
* SC: Can you add that add a comment to PR (WT)?

ACTION: WT to comment on PR

* HS: One thing I noticed is that there's often "seeAlso" to a doc that is access controlled. This needs to be thought about.
* SC: If it's not there and it should be then you might need an action.
* HS: *grumbles*

ACTION: HS to comment on the PR.

* eP: I agree. I will put all details on PR. The profile is focused on the individual. Is there a plan to have it for organizations? Both are agents/denoted by WebIDs.
* SC: There has been discussions on expressing things other than a person, orgs. Right now we might be able to capture on the current profile spec, not sure there's a need for a separate doc. It will definitely cover orgs. And groups.
* eP: There's also conversatioons to denote applications.
* SC: Alright. That's all good, that's all in the scope.

ACTION: eP to comment that on the PR. Maybe suggest links with existing vocabs.

* SC: foaf:Agent covers "living things" (people, orgs, social entities) not software agents.
* eP: org vocab is subclassing `foaf:Agent`
* SC: there's nothing in foaf covering software.
* HS: it says [foaf:Agent](http://xmlns.com/foaf/0.1/#term_Agent) is a class of agents (things that do stuff). (URL to foaf spec please), it just gives a few ideas about what an agent is. From the html doc:
> The foaf:Agent class is the class of agents; things that do stuff. A well known sub-class is foaf:Person, representing people. Other kinds of agents include foaf:Organization and foaf:Group.
* SC: `<http://xmlns.com/foaf/0.1/Agent> <http://www.w3.org/2000/01/rdf-schema#comment> "An agent (eg. person, group, software or physical artifact)."` .
* SC: In past meetings we discussed `acl:client` or `acl:agent` to refer to clients ( https://github.com/solid/web-access-control-spec/issues/81 ). I mentioned things that would be necessary to use `acl:agent` as an existing property, but the definition in natural language might need to be updated. Good news that `foaf:Agent` already covers it. It's feasible to just have `acl:agent` provided we update. `acl:agent` has range `foaf:Agent` only description doesn't cover agent. Mechanically it's fine.
* HS: what this ShEx is doing is for person. you can have one for software agents and organizations. And these would have different shapes.

### Social profile as discovery mechanism
URL: https://github.com/solid/webid-profile/issues/65

* SC: Topic proposed by WT.
* WT: I brought up that issue to indicate something that i find a bit strange and will influence data discovery.
* WT: When we see a WebID profile doc, as used today, there's stuff that's in the shape we discussed today: names, addresses, etc. But on the other hand, we are defining mechanisms to let apps discover out data. For example, we have type indexes to point to where certain types of data are stores, and we have interop spec doing something similar with shape trees. My issue with this is once you start adding data to the profile doc, it is either duplicate data that is discoverable via other discovery mechanisms, in which case it has to be kept in sync, or only available in that profile doc, so the question is what data should be stored where? if I'm an app and i want your address, your photo album etc. do I look in your profile or use type indexes or interop registries? My intuition is that the profile document itself shouldn't contain any data, only pointers for discovery. that solves issues of duplicate data and where to find.
* eP: I agree. Especially when we think about AuthZ, one case when data is public or protected info. The paper of Ruben Verborgh and team (ref???) using the case of birthday and so on, it is similar to email address, sometimes you want to share full name, first name... sometimes you want to make everything public. For that information AuthZ should happen before discovery. +1 to take advantage of existing discovery mechanisms to discover data. For different audiences you can select different. vcards they have access to instead of trying every seeAlso blindly. We need to work around some use cases from Ruben's paper and see how it can work, have different proposals. In general I agree discovery needs to be taken into, and preceded with AuthZ for protected information.
* DB: Last time in the WebID meeting I remember Tim saying he was interested in having the possibility of a minimum profile. Name, pictures, things apps would consume in a daily basis. Reduce amount of hops for this popular information. Could there be a distinction of priorities in data?
* SC: That's an old design pattern that has been in Solid. Just to make it useful. We're talking about Social linked data, the basics, even if it's a pseudonym, it puts something on a screen. If people want to put their real photo in a different location, that's fine. There's a distinction between making some info available for the utility of it, not so much exposing it. You can have anonymous and pseudonymous WebIDs.
* WT: I agree that it is important that apps can access important information quickly. But I'd like to raise: 1 - it is quite naive to think that we know what apps will need now or in the future. Even if we decide it's a good idea to have these things, I think they should be in there using some mechanism that relies on the standard discoverable place where they are. You can imagine we store all data even names and avatars in the interop registries, but we let the authz agent/server of interop make it so that if you declare that a certain type of data is public, then ??? is added to your WebID profile. Just brainstorming.
* HS: I think we should also be careful about premature optimization in this case. The argument that you following links might be problematic because it might lead you nowhere, that's something you can deal with but expensive. You can have a version 2 of Solid that allows you to specify filters, it could be really complicated, because we're working on consensus... ??? we def could do that, but it's going to take a long time and resources to build. If we look at Mastodon, it's got public profiles. You can put your picture up... so we def wanna get to the point of military grade security but let's avoid tying ourselves into knots. Let's not build again security, that's it.
* SC: We do have an understanding that if we can have a solution that you can extend to a point where you can have the basic thing now and leave enough space to solve that part later... without breaking changes... sometimes we're looking for a balance.
* eP: +1 to avoiding premature optimization. We need some grounds before we start improving.
* eP: We need to work based on combined use cases, I think about social graph use cases, because then we have authz and security considerations we have address book and agent registry in SAI and we need a consistent way of working and presenting information. We need for example to prevent phishing because of people impersonating others. when it comes to social graph, There are some issues on github related to working with info about individuals, specially on contacts later used for authorization.
* SC: Let's pause. We can continue on WebID-Profile meeting on Tuesdays at 16:00UTC.

### Quick note on Mastadon

* HS: At the IETF meeting in London last week, it came up that Mastodon is using an old version of HTTP signature. Mastodon is using version 6 which is 7 or 8 years old. I thought it'd be worth mentioning. Links to Mastodon code and documentation available from here:
https://mathstodon.xyz/@bblfish/109326189343436621
* HS: See especially the [Mastodon docs](https://docs.joinmastodon.org/spec/security/#http).
* HS: The [HTTP signature](https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-13.html) is progressing to the finish line, so I'm going to start doing a rewrite and cleaning up. If people are interested we can meet in the Web authentication panel.
* HS: I will be working on improving the Solid Http Sig spec, which makes use of the ietf docs.
https://github.com/bblfish/authentication-panel/blob/main/proposals/HttpSignature.md

### Storage Description
URL: https://solidproject.org/ED/protocol#server-storage-description

* SC: On discovery of storage description resource via `http://www.w3.org/ns/solid/terms#storageDescription`
* SC: Background: https://github.com/solid/specification/issues/355
* SC: Currently also used to discover information about Notification Channels: https://solid.github.io/notifications/protocol#server-link-storage-notification-channel
* SC: but.. we need solid implementation feedback. Commitment to implement.

* SC: A high overview: In the editor's draft we have a link to a requirement (link?) issue #355. If you haven't seen it please do.
* SC: The term is proposed to be in Solid Terms vocabulary. Proposing to include the property to describe the storage description in the Notifications Protocol. What we're saying is when a client wants to find out information about notification channel, 2 ways: one is through storage description. We agreed we will keep that in the notifications protocol spec, now it remains there and published eventually. If that changes we will need to consider another way. Raising as topic because it's part of the Protocol where there's uses, on paper it sounds great, but that is not always enough to keep it in the spec, specially an ED, a good signal would be to have multiple implementations, or come up with an alternative proposal that meets the same use cases. Hoping that if you haven't come across it you'd give it a look. Relatively easy to implement, but we still needs to see implementations (servers or applications) making use of that discovery, or a commitment to implement. Signals of that sort are important. Even if you say this makes no sense, that's as useful as commitment to implement. That's how we know if it needs to be on the spec. When we have tests for these things and need to show implementation reports, the results will show whether that particular implementation agreed to use that, and if not implemented, we can remove from the spec. That's why we go through this process. That goes for any feature or solutions that we have in the spec. If no one will implement a certain feature, we need to focus on low hanging fruit.

---

### Considerations section
URL: https://solidproject.org/ED/protocol#considerations

* SC: An overview about this section and request for comments.

### Forming a W3C Solid Work Group
URL: https://lists.w3.org/Archives/Public/public-solid/2022Nov/0001.html

* SC: If TimBL present...