---
# System prepended metadata

title: 'W3C Solid Community Group: WebID Profile'

---

# W3C Solid Community Group: WebID Profile

* Date: 2022-08-30T16:00:00Z
* Call: https://meet.jit.si/solid-profile
* Chat: https://gitter.im/solid/webid-profile
* Repository: https://github.com/solid/webid-profile

## Present

* Virginia Balseiro (VB)
* Jeff Zucker (JZ)
* [Sarven Capadisli](https://csarven.ca/#i) (SC)
* Timea Turdean (TT)

---

## 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

* [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

## Topics


### Separation of index content
URL: https://github.com/solid/webid-profile/pull/43

>ACTION: Have RV clarify committent to type-indexes.

* SC: TT to follow.

>ACTION: TT to follow-up on PR, copy the type-indexes document into its own repo. Remove type-indexes from webid-profile repo.

* TT: We need to decide on the repo name.
* TT: We have two options. Either make it specific to type index and call it `type-indexes` or concept higher and say `solid-indexes` and type indexes would be one flavour, which happens to be the only one now. And the other question should the name be in the repo or not.
* JZ: Don't have a strong opinion.
* VB: Neither do I.
* TT: RV didn't respond to my proposal either. I have a preference for `solid-indexes` and make type index as one. In that way, the introduction part will talk about what would an index be? A lot of people misunderstand it. IN the introduciton, leave space for query purpose or others types of indexes.
* SC: Find type-indexes more specific/clear. Repo being for that spec. If other indexes, e.g., xyz-indexes, they'll go into other repos.

ACTION: SC to create `type-indexes` repo.

>ACTION: JZ to update webid-profile, removing type-indexes.

* JZ: Basically waiting to re-write the whole thing. I guess it'll be simpler ot take that stuff out . Will do this week.


### Proposed Conformance Model
URL: https://github.com/solid/webid-profile/issues/40

>ACTION: JZ, VB, TT to invite others to comment on issue.

* JZ: Wrote messages and pinged people. Had 10 people respond. Still would like to hear more.
* JZ: Anyone else reach out? Anything else we should do to get input?
* VB: I can have an action to ask Emelia. I can ping other people in other communities, maybe in Women of Solid chat.

* JZ: Summary: https://github.com/solid/webid-profile/blob/main/notes/Summary-of-Feedback-on-Conformance-Rules.md
* JZ: First item there... came to the conclusion: we shouldn't say anything in the conformance rules about the OIDC Issuer.. in the non-normative section we refer to it that it is the most popular form of ???
* JZ: Does that sound right for everyone?
* SC: Is that about re-design?
* JZ: Do you agree to have a conformance rule.. but have a non-normative section for it.
* VB: Sounds good.
* JZ: Rather than having a rule. Required by WebID PRofile but required by Solid-OIDC, if that's what you are using.
* SC: That's close to my comment on that particular requirement. So, +1 on updating.
* JZ: The class I proposed `solid:SolidProfile`. There are two problems.. the personal preferences documents is used, but we don't want anybody trusting it that it is the solid profile. The only way is tha tit is dereferenced from the webid or from the solidprofile predicate. So, we don't need a class that this is a profile.
* SC: Clarify `solid:SolidProfile` / `solid:ProfileDocument` as to what's intended.
* TT: I don't have an opinion. I don't see a bad consequence to removing it.
* VB: Good practice but don't need it. As you said, we can't assume that it is linked from the WebID document.
* JZ: We'd still keep the predicate `solid:profileDocument`.
* SC: Abstain until I see a revision.

ACTION: JZ to clarify `solid:ProfileDocument` and to remove it.

* JZ: SC said in his document too... said in the conformance rules where in every case .. everything about the WebID is from the WebID spec. Instead of repeating, we'll quote them. Won't reinvent.
* JZ: Especialy in that what th webID document MUST do. So, it must do what the WebID spec must do. In the same way for Solid OIDC. Any objection?
* SC: {Notes no objection}

* JZ: ??? should be readable.. placed in the preferences document or see also document. That would provide the same functionality or not allowing other people access it but it would stay within the same framework. On the other hand, is there a reason that people can't do that or people can't make it private or restricted? It seems less flexible but I don't know other reasons.
* VB: What's stopping aynone making their profile document private? so should we accept they should make it readable? if they are separate maybe; the webid and profile. the other concern I have - an open question - is it a good idea to have something public by default instead of private and then making it public.
* JZ: We're saying that the document has to be public but we are not saying what needs to be in there. One may want all their stuff in seeAlso. The rpofile document will be public and the seealso document would be private. In that case only those specificed can access it.
* VB: Elsewhere I noticed that you said the conflicting.. So, how would I include the seeAlso from the webid.
* JZ: I don't remember that... If we want to have private by default you put all that in the preferencesFile. There would be a public profile and it owuld link to that in which only owner would follow. That would accomplish the private file but not necessitate that profile be private. There'd be a single link. Would write it in the preferencesFile.
* VB: What about the other concern where people make it private and they expect it public?
* JZ: They can do anything with them. App developers need to be aware that this is all possible - a valid Solid profile would do this.. if we differentiate the situation where the profile is private and.... my opinion would be, that would work, and nothing int he spec prevent that from working. If you put everyhting in public and make it private, it would still work for the owner. It would not be a valid profile for anyone else.
* VB: ESS currently doesn't make anything public.
* JZ: Lets say I'm an app and I get there, .... what is the advantage of doing that instead of putting into the preference document?
* VB: I don't know the advantage but I don't understand why it must be public by default. From a UX perspective, or maybe app developers that would tend to default to that profile. Some may feel that it sohould be private and change to public.
* JZ: Not disputing that. People/servers should provide that by default if they want. Just saying that the way that's done... the profile document has to be public and private information goes to preferences. If X wants to provide private profile, put in preferences and later move it to the public.
* VB: Why? What is the advantage?
* JZ: Then all profiles behave the same. If you want to restrict / available to public, then you have to do that.. move into different documents. Here is another reason: ours is not the only spec that will use the Solid Profile. For example, an authorization-agent may want to read the public profile then run the authorization agent to see what right to see. In that situation that wouldn't work.
* VB: Makes sense.
* JZ: I'm not 100%.. if people are still uncomfortable, lets see it.
* VB: Need to think about the requirement.
* JZ: Let's leave it to open for now then.

ACTION: VB to ask out there for perspectives.

* JZ: I'm strongly against multiple profiles & multiple preferece documents. Then you have to load all the seeAlsos then look at each. Where if they are coming off preferences document, then forget about it.. and those don't exist.
* VB: I have a proposal for this. I think we should allow them but not require apps to follow all. Because i might have the UC where I have multiple profiles for work or leisure. I might have an app that lists those alternative profiles but doesn't load them. Just lets me switch between. There can be a UC where an app doesn't load but can follow if it wants. I htink we shouldn't rule this UC out. It is not necessary for an app to follow.
* SC: PAYGO principle / FYN.
* JZ: Why wouldn't those go into rdfs:seeAlso for specific audiences?
* VB: Isn't that what we are discussing?
* JZ: ...
* VB: Do you mean seeAlso from the main document.
* JZ: Angelo asked why we have to specify one profile and one preferences file? What you are talking about could be covered by rdfs:seeAlso.
* VB: You mean the one that links from the WebID profile?
* JZ: Yes. Those two documents can go into any seeAlsos they want.
* JZ: Only follow seeAlsos that you have access to.
* JZ: Your point on sameAs.. that can be there as ??? it indicates that there is additional information but not all apps are required to follow but free to follow if it wants.
* JZ: So, we agree on one profile and one preferences file? I meant the main solid profile document. Okay to leave those?
* JZ: Now SC's comments... oh my.. I don't have the answer to this one. Angelo brought up, WebID is the subject and app goes from profile to seeAlso.. and seeAlso it is only looking for WebID as subject. What if WebID is the object?
* VB: Wouldn't that be in the description of the Event, in this example?
* JZ: That's what I thought that it would go into the type index...
* VB: Wouldn't I use ???
* JZ: Schema that has a lot of different directions.
* JZ: Is an app required in the profile or in the seealso that don't have the webid as the subject.
* SC: Good quesiton. For resource-centric access control, that is most certainly the case. If you can read the resource, you get the compelte description. If/when we have statement level access controls, that may not be the case in the end. So, for now, assume that an app will read - even worse case scenario - the whole document. And there is no way to prevent an app or have an error handling on if/how they read the other statements. If they want to use that, they can.
* JZ: Do we need ot require the apps to look at it?
* VB: I'm thinking from my perspective, I don't know how that would work. Having to read the values to have a full profile. Maybe not as a requirement.
* SC: Just say, "statements of interest" that has to do with the WebID.
* JZ: Right now it says you MUST read all statements with WebID as subject and you MAY read any other statement.
* SC: Sounds fine.
* JZ: IIRC, we say something nicer than that in the document.
* JZ: Will do SC's comments next week.

ACTION: JZ edit the top of issue 40 to reflect on the changes based on what we agreed here.


### Document know privacy issues with Type Indexes and Trusted Apps
URL: https://github.com/solid/webid-profile/issues/16

>ACTION: Revise the SHOULDs in the type indexes on when an app wants to make data public/shareable.

>* JZ: This belongs in the type index spec, should be moved there.

>ACTION: Review with Tim on trustedApp

>* SC: TODO?
>* JZ: We need input on the conformance model, the separation of the type indexes, and the trustedApp . 

* SC: TODO. Revisit next week.
