-
Notifications
You must be signed in to change notification settings - Fork 9
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
f62d4fd
commit 8e41052
Showing
1 changed file
with
114 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,114 @@ | ||
| * Date: 2023-07-31T15: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](https://virginiabalseiro.com/#me) | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * [Timea Turdean](https://timea.solidcommunity.net) | ||
| * Seila Gonzalez | ||
|
|
||
| --- | ||
|
|
||
| ## 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 | ||
|
|
||
| * Virginia | ||
| * Timea | ||
|
|
||
| --- | ||
|
|
||
| ## Introductions | ||
|
|
||
| * name: text | ||
|
|
||
| ## Topics | ||
|
|
||
| ### Type Index spec - core concepts - discussion | ||
|
|
||
| * URL of examples to be discussed: <https://github.com/solid/type-indexes/discussions/24> | ||
| * VB: Proposed by TT. | ||
| * TT: Was waiting for Sarven's input but I feel I need clarification on some points. For example, I don't grasp how tis is related to your PR. I realized that it's hard to divide and conquer on this topic. If you only take one particular requirement and discuss it you lose track of how we name things. SC's comments ae more or less all over the place so don't know where to start. | ||
| * VB: You went through the thought process I went through. Describing conformance and classes of product. I see those two related in this way. | ||
| * TT: Do you mean PR#98 in WebID-Profile? | ||
| * VB: Yes. | ||
| * TT: So we possibly have different approaches/styles. It's hard to make that connection. Figuring out what I need to reference from others. How to align definitions/wording in a way that is under Solid style. I don't know how to tackle this. | ||
| * VB: What do you need / how can people help? | ||
| * TT: It'd be helpful for someone to indicate "I need to use WebID owner", okay it's defined somewhere else so I can take over. But also different entities: user, anonymous user. You talk about ReaderApplication and I possibly talk about the same thing but I name it something else. Is this actually work necessary? Is this what the goal should be that we have the same concepts? | ||
| * VB: I don't know if it is necessary to name the different things in the same way. We may want to see if we can align on the terminology: produce, consumer etc. Especially when people come from one spec to another. | ||
| * TT: Not so much what we want, but a requirement of the spec. | ||
| * VB: Right. | ||
| * TT: Besides the references, WebID reference and there's also naming "subscription server" coming from the Notification protocol, besides WebID owner and subscription server I dont'y know if I am missing out on naming something. | ||
| * eP: I think SC mentioned subscription client such as an example. Notifications is using skos:broadMatch. Just giving an example on how to align on specs. | ||
| * TT: I suppose I have to wait for WebID specification to make the definition of concepts and I simply reference or use the same. Maybe this is the conclusion? | ||
| * VB: I think we need more input weather it is necessary. It sounds like a good idea but maybe it should be blocking your work. | ||
| * TT: I find it so difficult to follow changes in HTML. | ||
| * VB: I failed to add the html preview and html diff to my PR. I was working to setup a github action on specification repo and possibly this one. Linking to preview and diff could be automated. | ||
| * TT: Haven't looked at WebID-profile in a while and was overwhelmed by HTML. Was demotivating. I will try to work with this feedback, do some rewording where I canand have question marks open on the concepts I see and see if we can align/have better definitions. Go concept by concept. And bring that to the meetings. | ||
| * eP: Always option to use bikeshed. I know SC prefers HTML+RDFa but there's this other option. For example solid-oirc is using that... quite a few specs are using this pre-processor. | ||
| * eP: Sidetracking a bit to understand TypeIndex work: in TI you have public TI and private TI, let's imagine we have photos in both, public and private. Each of those has an instance container, but what happens when you add photo to one and then change your mind and want to make public/private? Can you change or stuck with initial decision? | ||
| * TT: AFAIK you're kind of stuck. If you wanna change your URI will change which is similar to rebuilding your index. | ||
| * SG: In case of going private > public you only rebuild the public index, if public > private you have to rebuild both. | ||
| * eP: But IRI of the photo has to change, because you have to remove from one container to the other. We have plans to make an equivalent , and put some work into looking into TI, might be worth to come back to those fundamental issues and address them before polishing the conformance because I think there are bigger problems. Also privacy is not being addressed by exposing the full index to an app with access to it. Take a step back and try to work on those problems. Fully interested in sharing the experience in interop panel and how we arrived at decisions we made in SAI. | ||
| * TT: I fully agree. There are exactly these two points that are problematic, I am aware. With some version I put it into privacy considerations. | ||
| * eP: You only mention for public but also applies to private, because application can access private TI and know everything I have. Considerations only mention public. | ||
| * TT: True. I can change that and can also add the second one. From my perspective the work on TI spec was never to improve these problems. Those are known problems, different solutions, then a different index spec can be written. This is why we separated TI/webid-profile, to foster different indexes in the future because this one has shortcomings. I don't think this is going to be the future of Solid, but right now we don't have any solution that's implemented and works and people can understand. For certain use cases this is enough, but enterprise level solutions, TI is not good. TI is an example specification version 0.1 which was precursor if future more amazing indexes. I personally don't have the knowledge to improve this TI without talking about registers or... Goal was to capture what exists today, but being frank about consideration and let people make their choice. | ||
| * eP: Okay that clarifies a lot. I can demo SAI in another meetings. We currently have different functionality wiht more support for other use cases. I have open source implementations. Can also try to write down which problems in TI are addressed in SAI. | ||
| * TT: For this version I am very interested in pointing out the limitations so developers can make educated decisions. If there are other implementations that's great, basis for building a better spec which is what Ruben want it all along. We need to make sure it is reflected on the WebID. | ||
| * eP: So this is not intended to go into WG? | ||
| * TT: I don't know. | ||
| * VB: I don't think so. | ||
| * eP: Fits into client-client. | ||
| * VB: Right but that's CG. | ||
| * eP: Right so we're not intending to include in WG. | ||
| * VB: No. | ||
|
|
||
| ### Conformance section | ||
|
|
||
| * URL: https://github.com/solid/webid-profile/pull/98 | ||
| * VB: Some background to some of the things the PR touches on: https://github.com/solid/webid-profile/blob/main/meetings/2022-11-01.md#podspaces-webids-discussion | ||
| * VB: i saw the comments but did not have time. Should we go point by point? | ||
| * eP: There are few inline comments which are small things about namespaces and typos. Question about sameAs, which is a bit more involved. The other part the intention was I complete approve this PR but keeping in mind that more fundamental things need to be addressed. I approve with this understanding. | ||
| * VB: let's discuss sameAs. I think my language was unclear - it's a note in the section about 'how to add an extended profile' and how the application should add it to the profile to be discovered. What I was trying to say: if you have another webID that represents you, it should be under sameAs. If I have my main webID and I have a list of webIds from Inrupt, but also me, it should be under sameAs. | ||
| * eP: It could be clarified. ... we link the webid sameAlso and .. it kind of leaves me thinking we are talking about same type of document when actually you want to talk about another webID. sameAs webID, we are not talking about linking extended profile document with sameAs. | ||
| * VB: Ok I will clarify this note to make this clearer. | ||
| * eP: This could probably deserve a dedicated small section and the note link to it. Because they are two very different things, linking to an extended profile vs linking to another WebID. | ||
| * TT: also agree. | ||
| * VB: Great suggestion, I like that idea. Will make changes to the PR. | ||
| * VB: the other issues... | ||
| * eP: I do not see them blocking the PR. Either there are prio conversations and they only need to be tracked and addressed. WebID is not required to be ina. Solid Storage and we should leave it opne that it could not be there. It should not be required that a WebID must be hosted in a Solid Storage. And maybe we should adress the options. | ||
| * eP: loos coupling: all the predicates used in webID doc or webID profile could be visible in some registry, like notifications registry types. Have some dynamic way to keep this info. For example interop has authorization agent. At some point, we should be able to add it to add it to these types of predicates. inbox, storage, preferenceFile should not be directly listed here. I added that the preferece file is under specified. | ||
| * VB: yes it belongs in its own spec, we only have a small reference in a small section but not more. | ||
| * eP: it would be better to have it as separate spec. WebID profile should just provide a mechanism on how to link and it should link to teh other spec, how to connect to authorization and so on. | ||
| * VB: the WebId is not required to be in a Solid Storage. We went around this topic quite a while - we mentioned that is it is not in the Solid Storage then this spec does not apply because we cannot assume that any Solid operations can be performed on it. | ||
| * eP: this makes it complicated. If someone wants to use Solid or not, sort of needs a parallel spec than to define how to... WebId draft will be adopted by Solid WG. i am trying to understand how this will layer on top and what Solid Protocol will work with it - will require or use WebId. Do we depend on pure WebID or on WebID Profile? Since this is a question related to solid:oidcIssuer. It would be aqward if it depends on WebID spec but does not reference WebID profile. if the WebId Profile wants to say that it is only on a Solid Pod than what about when it is not? | ||
| * VB: we did not answer that in a straight forward manner. It feels like there is an issue to have both kinds of docs coexist. Having it i na Solid storage or the other option are really hard to reconciliate for all use cases. We need to open a discussion here. | ||
| * eP: maybe discuss around UC to make it concrete and find a way to take a direction. But it would clearly show the motivation behind it, and will show why certain decisions were made. There is a PR with UC: https://github.com/solid/webid-profile/pull/80. | ||
| * VB: I need to update it and merge it. you can add comments. We have a list also of UC itself, that PR that you find is because we will discuss if we have a section in the spec or a dedicated doc. We have a list of very general UCs but we should probably have more detail in considerations. The way I wrote this conformance section allows for all of that but it is very hard to support all UCs and still be interoperable and fit all UC. We need to answer this question of this spec applies only to solid pod hosted WebID or not? | ||
| * eP: i believe one liner will not be enough, it should not be able to chnage my oidcProvider. The UC should detail that when i authorize the app, when i set my prefered languages it should say that it cannot change the oidc provider. We derive UC from spec but we should use the spec to clarify UC and discussions. From UC we can set a few requirements and we can showcase, or demo implemetation, with code snippets how this UC can be satisfied using the spec. | ||
|
|
||
| ACTION: VB to merge PR as is and follow up with issues/PRs. | ||
|
|
||
| * VB: Please go and comment on the PR and add use cases/details. | ||
| * VB: if the server has any triple that the server does not have change it would have the choice to deny the changes. | ||
| * eP: if it is closed set it might work but if you want to allow to be extensible, this becomes harder because the servers which do not implement something, they by default could deny. Server needs to treat it protected. I see it problematic with an open set, as servers add more protection for open triples is difficult. To have 2 separate resources protected and unprotected might be safer. You can decide which spec is authoritative for it and look at the other resource. It simplifies this problem between the timing between protected and unprotected. I think it is a bigger discussion. It follows a per resource access approach. | ||
| * VB: UC would be super helpful. The problem is that with the solution of all docs being protected or not in the Solid Protocol, or editable by certain apps or API or whatever, the problem is that it will open other issues of interop of WebID profiles which we also tried to solve. | ||
| * eP: is there an assumption that any app that acts on behalf of the user can edit WebID profile or the user need to authorize an app what they can access. if we said the WebId is by default not editable without permission. ... WebId profile can be added by agent that uses my webID and can granurally access what resource. I think there needs to be some kind of user authorizing the app to do that. The assumption is there is no granularity. | ||
| * VB: I do not think there is that assumption but it depends on the particular implementation. | ||
| * eP: it depends on the authorization policy: ACL or ACR and that is the authorative. What are the expectations from the acces policies? Or is it wharever user says? | ||
| * VB: this particular spec does not get into any of that. In a way it is asuming or describing how to perform certain actions. But I do think that we mention somewhere, that you can also not have access to something and that could be expected. We are not always talking about the user's webId: think about me reading my friend's webID. Access Control depends on the server inplementation. It would be useful to have a UC for 'if you have a time to have a triple that should be protected but it is not'. I will think about it. | ||
| * eP: I approved the use cases PR and we can follow up with follow up PRs to just structure it better. |