search

solid / webid-profile

Discovery based on Solid Social Agent WebID
https://solid.github.io/webid-profile/
MIT License
11 stars 8 forks source link

Proposed Conformance Model #40

Closed jeff-zucker closed 1 year ago

jeff-zucker commented 1 year ago

[EDIT - updated based on Editor's meeting of 2022-09-06, but not including all the comments since last update. This model is likely to change]

Given that IdPs may wish to restrict how WebID Documents behave, including limiting the ability of the WebID owner to write to the document, we need to support the ESS-like model in which the WebID document is not the same document as the Profile document.

If we proceed as I've outlined below, we would have two shapes which can occur in one document or in two documents. In the NSS-like instance where the same document is both the WebID document and the Profile document, it would need to conform to both shapes. In the ESS-like instance the WebID Document could be very minimal and the Solid Profile Document would conform to the same shape as all other Solid Profile Documents.

I also propose a solid:profileDocument predicate. We can add a note that, for backward compatibility, developers may wish to also check for the foaf:primaryTopicOf predicate.

Solid Profile Data Model Conformance

The Solid WebID Document

This document should follow the rules set forth in the WebID Specification including (TBD:get exact wording)

And it should follow this rule, introduced by this spec

In order to be usable for purposes of verifying identity, a WebID document should also contain predicates mandated by the identity protocol in use. For example if the Solid-OIDC protocol is in use, the WebID document MUST include a triple equavent to <?WebID> solid:oidcIssuer <?Issuer>. See the Solid-OIDC specification for details

The Solid Profile Document

The Preferences Document (space:preferencesFile)

Extended Profile Documents (rdfs:seeAlso)

Note: Apps can be expected to examine triples in seeAlso documents with the WebID as subject. They are free to but not required to examine other triples.

Note: Apps are free to but are not required to examine triples in seeAlso documents using the rdfs:seeAlso predicate.

jeff-zucker commented 1 year ago

All of which yields this updated diagram discovery-newer

ThisIsMissEm commented 1 year ago

@jeff-zucker I think you've some typos in:

it MUST either label itself as a Solid Profile Document using a triple equivalent to <> a solid:ProifleDocument. or include a pointer to a Solid Profile Document using a triple equivalent to <?WebID> solid:profileDocument <?SolidProfileDocument>..

Did you mean:

it MUST either label itself as a Solid Profile Document using a triple equivalent to <> a solid:ProfileDocument. or include a pointer to a Solid Profile Document using a triple equivalent to <?WebID> solid:profileDocument <?SolidProfileDocument>..

jeff-zucker commented 1 year ago

@ThisIsMissEm - sorry, I don't see what you are referring to. What is the difference I am missing?

gibsonf1 commented 1 year ago

Excellent work, this proposal looks really good and solves some key issues around webid standards and discovery.

ThisIsMissEm commented 1 year ago

@ThisIsMissEm - sorry, I don't see what you are referring to. What is the difference I am missing?

@jeff-zucker a typo in the text of the issue, ProilfeDocument kr something instead of ProfileDocument

ThisIsMissEm commented 1 year ago

@jeff-zucker would also be good to see how this pairs with pim:storage

jeff-zucker commented 1 year ago

@ThisIsMissEm - sorry my eyes are not good enough to see the typo you are talking about. We mention space:storage (same as pim: but other specs seem to use space:) and say that it SHOULD go in the Solid Profile Document unless there are reasons otherwise. In other words, if ESS wants to write it in the WebID document instead, it can but if someone needs to write it, they should write it to the Profile Document. Personally, I think it is a mistake to put this in the WebID document because it forces the public listing of the storage. Better would be to leave it up to the user - it goes in the Solid Profile by default but they can move it to somewhere private or restricted if they want.

bourgeoa commented 1 year ago

For historical reasons, I feel that there should be a 2 step process :

This will help developers and server/app maintainers.

jeff-zucker commented 1 year ago

I'm afraid I don't understand what you mean by migration. Both types of profiles will continue to exist. They are both in existence now, this spec just takes that into account. I also do not understand what you mean by 2 step process. What would the steps be?

On Wed, Aug 24, 2022 at 4:10 AM Alain Bourgeois @.***> wrote:

For historical reasons, I feel that there should be a 2 step process :

  • the old NSS/CSS type could be referenced as 0.9
  • new project stating changes and some (if any) migration consideration

This will help developers and server/app maintainers.

— Reply to this email directly, view it on GitHub https://github.com/solid/webid-profile/issues/40#issuecomment-1225574502, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKVJCJG5ZLJGURPZG5IIJWLV2X7JHANCNFSM56SQD3ZQ . You are receiving this because you were mentioned.Message ID: @.***>

elf-pavlik commented 1 year ago

Given that IdPs may wish to restrict how WebID Documents behave, including limiting the ability of the WebID owner to write to the document, we need to support the ESS-like model in which the WebID document is not the same document as the Profile document.

Can I find somewhere more details about the ESS-like approach and the reasoning behind having a separate WebID document and Profile document?

jeff-zucker commented 1 year ago

I've gotten my information on the subject from Aaron, Virginia, Samu, and ThisIsMissEm at Inrupt. I don't know whether Inrupt has documented it anywhere, if you find such documents, please let me know.

[EDIT : All of these folks were kind enough to talk to the editors of the profile spec, they are not responsible for this document which does not represent their thoughts, rather the understanding of the spec editors of their thoughts]

Otto-AA commented 1 year ago

The proposal sounds good to me, thanks for working on this @jeff-zucker. The only concern I have here is the number of requests, as all of them have to be done sequentially which requires multiple round trips between the client and the pod. However, I think this is acceptable, because we only need to do this once and then can cache it for some time.

jeff-zucker commented 1 year ago

@elf-pavlik - the reasoning behind the approach, as I understand it is that the Identity provider and the Storage provider can be different entities and that the Identity provider may or may not allow writing to the WebID Document. Identity providers should have very few restrictions on the WebID document because they may be serving a variety of protocols. Additionally, some IdPs feel there is a security concern with having the solid:oidcIssuer predicate in a user-writable document. So, in order to put the minimum requirements on the Identity Provider, we say only that the WebID document needs to point to a document that is writable by the WebID owner, not that it itself be directly writable.

elf-pavlik commented 1 year ago

Thank you @jeff-zucker

Additionally, some IdPs feel there is a security concern with having the solid:oidcIssuer predicate in a user-writable document.

I understand that WebID Document has specific security requirements, and possibly not be handled by ACP/WAC rules, and have dedicated IdP provided UI to modify it. At the same time, I'm not convinced about locking the WebID owner from any modifications to that document. We have discussed that some Resource Servers (storages) may require authentication from a very specific OP (OIDC Issuer), ACP has acp:issuer matcher designed for that.

Another question would be on the extensibility of the WebID Document, for example, solid:oidcIssuer appears here even though Solid-OIDC is the spec that requires it.

We have a very similar case with interop:hasAuthorizationAgent, required by Solid Application Interoperability

I don't understand which specification would have the other as a normative dependency. And if solid:oidcIssuer would be mandated by this spec, should we also submit interop:hasAuthorizationAgent here? We can think of it as AuthZ counterpart for the already included AuthN predicate.

jeff-zucker commented 1 year ago

I personally also agree that it may not make a lot of sense to lock the WebID owner out of modifying the WebID document but I don't see how we can be in the position to require servers to allow it.

Good point about the solid:oidcIssuer. My thought is that the Solid-OIDC spec is the normative one and that we refer to it. All of the conformance rules for the WebID document with the exception of the solid:solidProfile predicate are based on the SOLID-OIDC spec and we should be explicit about that. [EDIT, on second reading, this paragraph doesn't make sense, please ignore it. See below for better discussion of this issue]

jeff-zucker commented 1 year ago

should we also submit interop:hasAuthorizationAgent here? We can think of it as AuthZ counterpart for the already included AuthN predicate.

No, I don't believe it should be part of this spec. Our spec defines a very basic profile. We will enhance the final section "Other Predicates" to say that our spec is only one of the specs relating to profiles and that other specs may introduce further predicates and conformance rules required for its own purposes. We may name specific other specs here, or we may not.

This way our spec, the interoperability spec, the upcoming indexes spec, and future specs on personal profiles and organizational profiles will operate independently of each other. None of them should contradict each other i.e. forbidding something required by another spec, but other than that, I don't think they should really mention each other. This leaves developers and users choices. For example an app based on public data whose main purpose is to share data can work just fine without an authorization agent but, as you mention, that may not be the case for medical or financial apps. As you say, we should alert developers about security considerations, but in the end, it is up to them what they do about those considerations.

jeff-zucker commented 1 year ago

@elf-pavlik - my view is that this spec defines the expected shape and discovery method for some core profile documents. It does not address a) what indexes exist b) how apps are authorized c) what individuals and organizations can/should say about themselves. Other specs will deal with those topics.

scenaristeur commented 1 year ago

If a webid doc can "include a pointer to a Solid Profile Document", everyone can switch to any Solid profile doc. Today my webid doc can point to "a Solid app developer in France" tomorrow to a little Chinese girl in Mexico" and the day after my webid can point to "@timBL profile" . How can we know who is behind a webid doc. Can we be sure of any consistency? Personnaly I'm really disappointed with the way 'inrupt devs " impose their point of view to the community. I've been struggling with the remplacement of solid-auth-client by the inrupt new auth, there is another discussion about what should developer use wack/ACP and now big changes on the profile doc. I'm not afraid of changes but I think it is not a good way to develop something for the NSS and then push it as a spec for the community. There are big problem that Inrupt devs could help instead of changing what is working. I remember for example a longtime issue where @aveltens post a chat message instead of Tim, the fact that when we autorisé an app, it has acces to all the pod..

jeff-zucker commented 1 year ago

how can we know who is behind a webid doc. Can we be sure of any consistency?

The WebID doc must contain a solid:oidcIssuer predicate that points to an Identity Provider capable of verifying that a logged in user either is or isn't the person registered with them as the owner of that WebID. That part can be verified. The WebID document can point to a profile which says it belongs to the Queen of Mars. That part can't be verified, people can portray their identity any way they want. That has always been true, this spec does nothing to alter that situation.

I certainly hear your points about the new auth, the differences between ACP/ACL and other aspects Inrupt has introduced - these have all been extremely frustrating for app implementers. OTOH, I do believe all of those changes have made Solid more secure.

The change proposed here, in this issue will not mean any change at all for any server or app other than those on ESS and on future servers designed the way ESS is. It is NOT suggested here to accomodate Inrupt, rather because it is really to everyone's benefit for Identity Providers to face as few constraints as possible. Identity Providers may be using many different identity protocols, Solid-OIDC being only one. They also may have security reasons not to want users to write directly to the WebID document. So if they can create a WebID document that can't be written to directly, we need a way to say, look over there for the writable stuff. This lets the Identity Provider control and secure the WebID document but lets the user have full control over their own profile.

jeff-zucker commented 1 year ago

@scenaristeur wrote "everyone can switch to any Solid profile doc"

But there can only be one Solid Profile Document per WebID and it is guaranteed to be either the document at the WebID URI or a document pointed to in that document with the solid:profileDocument predicate. Apps should not believe something is a Solid Profile Document just because it says it is (and maybe that's a reason to not introduce the SolidProfile class) - they should believe it is a Solid Profile because they got there either directly or one-hop-away from the WebID URI.

elf-pavlik commented 1 year ago

Apps should not believe something is a Solid Profile Document just because it says it is (and maybe that's a reason to not introduce the SolidProfile class) - they should believe it is a Solid Profile because they got there either directly or one-hop-away from the WebID URI.

One could only honor statements that have the WebID as the subject or object. I think this is a broader issue with the provenance of statements which needs to be addressed when the application is merging multiple graphs/datasets.

This way our spec, the interoperability spec, the upcoming indexes spec, and future specs on personal profiles and organizational profiles will operate independently of each other. None of them should contradict each other i.e. forbidding something required by another spec, but other than that, I don't think they should really mention each other.

I think discussion in #43 is relevant, especially what @RubenVerborgh wrote:

However, we might still want to discuss where that description will be written down. Essentially, the question is whether we want:

  • the Profile document to have a dependency on the Type Indexes document
  • the Type Indexes document to have a dependency on the Profile document

I think the second option is the more sustainable one; indexes will still evolve, but the profile should remain constant.

If I understand him correctly I would agree with it. Further Solid-OIDC, SAI, and any other future spec could depend on minimalistic WebID/Profile spec. This spec could also introduce a directory that would link back to all the specs depending on it, a sort of list of dependents. This minimalistic spec could also provide guidance, security, and privacy considerations helping to decide which document (WebID or Profile) should be extended by another spec.

If for example in 2 years we will have Solid-GNAP which provides an alternative to Solid-OIDC, it would have a clear way of depending on WebID/Profile, in the same way, Solid-OIDC and SAI could depend already.

I think feedback from @acoburn and @justinwb as co-editors of mentioned spec would be very helpful.

jeff-zucker commented 1 year ago

@elf-pavlik, please raise other issues as you see fit and keep this discussion on the proposed conformance rules. I do agree with you and Ruben that this should be a minimalistic spec with no dependencies on other specs. I do not agree with you that this spec should provide guidance on or a directory of the other specs. The whole point of making it minimalistic is so that it can be completely orthogonal to those other specs and be able to work within the framework of any of them. If you wish to discuss this further, please raise a separate issue.

elf-pavlik commented 1 year ago

it MUST include one or more triples using the solid:oidcIssuer predicate

To be specific, I believe this doesn't belong here. Instead, Solid OIDC should have a normative dependency on WebID/Profile spec and have a normative definition of extending WebID Document (defined here) with solid:oidcIssuer (defined there).

This way future spec, eg. Solid GNAP could follow this pattern without needing of revising WebID/Profile spec to add solid:gnapAssertionIssuer (hypothetical) etc.

should we also submit interop:hasAuthorizationAgent here? We can think of it as AuthZ counterpart for the already included AuthN predicate.

No, I don't believe it should be part of this spec. Our spec defines a very basic profile. We will enhance the final section "Other Predicates" to say that our spec is only one of the specs relating to profiles and that other specs may introduce further predicates and conformance rules required for their own purposes. We may name specific other specs here, or we may not.

I believe this Other Predicates should be a separate living document which can be amended as different specifications develop. It would have a list of predicates used in the WebID document and Profile document. This would be a lightweight version of something like IANA Link Relations registry https://www.iana.org/assignments/link-relations/link-relations.xhtml

jeff-zucker commented 1 year ago

@elf-pavlik wrote

One could only honor statements that have the WebID as the subject or object.

We will address that elsewhere in the spec. In this case yes, the WebID must be the subject of the solid:profileDocument triple.

jeff-zucker commented 1 year ago

@elf-pavlik

it MUST include one or more triples using the solid:oidcIssuer predicate

To be specific, I believe this doesn't belong here.

That's an opinion we should consider. Maybe we should say something along the lines of "The WebID document must conform to the rules of an identity protocol (for example, Solid-OIDC) and include the predicates needed for that protocol (for example solid:oidcIssuer)."

jeff-zucker commented 1 year ago

@elf-pavlik - or perhaps you are right that it does not belong here at all. If it is removed, then the dependency tree would go WebID Spec <- Solid Profile Spec <- OIDC/InterOp/Index/New Specs. So my current thinking is remove solid:oidcIssuer, point to the WebID Spec for all conformance rules except the solid:profileDocument predicate. Explain in non-normative text that Solid-OIDC is the currently most widely used identity protocol and that therefore the solid:oidcIssuer can be expected in the WebID document.

smessie commented 1 year ago

Great, I have no specific concerns. I'm a fan of the space:storage part. Now, it will however require 2 requests to get the storage location, but as @Otto-AA mentioned before, we could cache this, and by choosing the <> a solid:ProfileDocument implementation this could be prevented as well.

When there is no specific reason otherwise, the ldp:inbox and space:storage triples MUST be written in the Solid Profile Document.

👍

ThisIsMissEm commented 1 year ago

@jeff-zucker could we allow the WebID Document to have "this document may include a space:storage predicate, however, to correctly find all pods for a WebID you would need to traverse the graph"

This would support ESS's model where the IdP + Storage work in tandem, and there's strict access on who/what can edit the WebID Document and who/what can create pods; The logic here is that an enterprise/government will likely want the Pod for your WebID to be hosted on their service and that you log in using their IdP, as to ensure that data privacy is maintained.

That is: ESS only allows specific applications to modify the WebID and to create Pods & associate them with a given WebID.

We currently have in production the following as a WebID Document:

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix solid: <http://www.w3.org/ns/solid/terms#> .

<https://id.inrupt.com/emeliasdktests>
        a                      foaf:Agent ;
        rdfs:seeAlso           <https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/extendedProfile> ;
        <http://www.w3.org/ns/pim/space#preferencesFile>
                <https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/settings/prefs.ttl> ;
        <http://www.w3.org/ns/pim/space#storage>
                <https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/> ;
        solid:oidcIssuer       <https://login.inrupt.com> ;
        foaf:isPrimaryTopicOf  <https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/extendedProfile> .

My understanding is that with this proposal, that would become: 

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix solid: <http://www.w3.org/ns/solid/terms#> .
@prefix space: <http://www.w3.org/ns/pim/space#> .

<https://id.inrupt.com/emeliasdktests> a foaf:Agent ;
        solid:oidcIssuer       <https://login.inrupt.com> .

<https://id.inrupt.com/emeliasdktests> a solid:SolidProfile ;
  space:storage        <https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/> ;
  rdfs:seeAlso           <https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/extendedProfile> .

Where https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/extendedProfile is a solid:SolidProfile

Am I understanding this correctly? (I might also be getting the turtle formatting here wrong, I don't often write turtle by hand)

jeff-zucker commented 1 year ago

The conformance model as written would permit you to put the storage in the WebID document if you want. But we still need to say that unless there are good reasons (such as you mention) it SHOULD be written in the Profile Document and not the WebID document (because we can't write to your WebID Document).

A use case where I would want to insert my own storage statements is a local host. If my desktop is running as a pod, I want organizing apps to be able to include it with my other pods. I might change the ports on it so I might change the storage triples. I can't do any of that if the storage predicates are only in the WebID document and the WebID document doesn't let me write. So apps should read looking for storage in either place and write to the Profile document when they write and the server can do whatever it pleases.

I'm afraid that no, your turtle is not built according to the model I am proposing. In the ESS case there are two documents the WebID Document and the Profile Document. The WebID document is minimal and has a solid:profileDocument predicate pointing to the Profile Document. This means that the WebID document doesn't need to follow all the rules (such as being writable by the WebID owner) that a Profile document has to follow. Extended Profile Documents are pointed to from the Profile Document.

Here is what an ESS WebID Document would look like in this model : 

<?WebID>
    a foaf:Agent ;
    solid:oidcIssuer <https://login.inrupt.com> .
    space:storage   <https://storage.inrupt.com/random-storage-name/> ;
    solid:solidProfile <https://storage.inrupt.com/random-storage-name/profile/card> .

The object of the last triple could be at any path and name and the document there should conform to the rules for a Solid Profile listed above i.e. be publicly readable, be writable by the WebID owner, have a mandatory pointer to a space:preferencesFile and optional pointers to rdfs:seeAlso files.

If Inrupt wants to default to profiles not being publicly readable, they should do so using this model and put all profile details in the space:preferencesFile or in an rdfs:seeAlso file connected from there . That way the Solid Profile Document is readable by the public but all actual information is not. All the public sees is that there is a private profile but that is not accomplished by making the Solid Profile Document itself unreadable. The colors on the chart above show which parts can be public or private.

ThisIsMissEm commented 1 year ago

I personally also agree that it may not make a lot of sense to lock the WebID owner out of modifying the WebID document but I don't see how we can be in the position to require servers to allow it.

Good point about the solid:oidcIssuer. My thought is that the Solid-OIDC spec is the normative one and that we refer to it. All of the conformance rules for the WebID document with the exception of the solid:solidProfile predicate are based on Solid-OIDC and we should be explicit about that.

Perhaps also keep in mind that nothing in the spec says that a WebID must be a solid dataset or writable resource; it could just be a turtle file on an nginx webserver. As long as it has the predicates expected of a WebID Document, then it can be a WebID. (Though you might have trouble if you only serve it as html or json, given client implementations typically expect turtle right now)

It just happens that NSS, and subsequently CSS implemented the WebID as being served from storage (like ESS 1.x kind of did).

The assumption that a WebID Document must be writable isn't backed up by the existing spec, so that's something were the spec left room for possibilities and we've seen drift in implementations.

jeff-zucker commented 1 year ago

@ThisIsMissEm - While the WebID Specification over eight years old now, does not explicitly say that a profile must be editable, almost the entire document is about writing to the profile so the assumption that the profile is writable did not come out of thin air. The approach in that specification of writing into the profile triples pointing to rdfs:seeAlso to support privacy of information was expanded in the first attempt at a Solid WebID Profile Spec about three years ago which has been the defacto standard for app developers up until now.

So, while this current spec supports the view that the WebID Document does not need to be directly writable via the Solid protocol, it also strongly supports the view that the Profile Document must be and that he document should follow the system of preferences and seeAlsos which have been the accepted practice for years now.

jeff-zucker commented 1 year ago

It just happens that NSS, and subsequently CSS implemented the WebID as being served from storage

I don't know the history of those particular decisions, but I do know that the structure of the profile, the seeAlso files, the preferencesFile did not "just happen". There were extensive discussions over years as shown in some of the documents I cited above.

angelo-v commented 1 year ago

Hi Jeff and all that are participating in that. It is a very important work. Thank you!

After reading through it, I am having a couple of remarks and questions. I did not read all the comments, please forgive me if I am mentioning something, that has already been discussed. I assume the current state of discussion is reflected and continuously updated in the initial post.

I do not get, why we need to differ between solid:ProfileDocument and foaf:PersonalProfileDocument. Whether I can read/write a foaf:PersonalProfileDocument via Solid Protocol can be determined by checking accept-patch and wac-allow headers, can't it?

The Solid WebID Document

there MUST be exactly one Solid WebID Document for a given WebID URI

Why that? And which of the two documents do you mean here?

it MUST be able to be dereferenced as RDF from the WebID URI

I assume this is already covered by the WebID spec?

it MUST be publicly readable

Why that? I can imagine private WebID (and respective documents) I am only sharing with my family or company. This feels like an unnecessary restriction.

it MUST include one or more triples using the solid:oidcIssuer predicate

That's a requirement of Solid OIDC and does not need to be covered here, imho. This spec should be independent of the auth mechanism.

The Solid Profile Document (solid:ProfileDocument)

there MUST be exactly one Solid Profile Document for any given WebID URI

Same as above, why only one? Of course my WebID only resolves to one document, but every document linked via rdfs:seeAlso could also be such a document?

it MUST have exactly one triple in the form <> a solid:ProfileDocument

As mentioned initially, why not stick with foaf:PersonalProfileDocument?

it MUST have exactly one space:preferencesFile triple

why only one? And it could be elsewhere in the extended profile, not necessarily in the "root".

it MUST be publicly readable

same as above

users can choose to restrict access to their inbox, and/or storages. In that case, the triples for them SHOULD be placed in the Preferences Document for fully private resources or in a seeAlso document for restricted audiences. When there is no specific reason otherwise, the ldp:inbox and space:storage triples MUST be written in the Solid Profile Document.

I am not sure if I understand that paragraph. Perhaps it should be split down. In the end I would assume that I can place my ldp:inbox and space:storage anywhere in my extended profile document or preferences.

it MAY have zero or more triples with the solid:community predicate

What is the meaning of that predicate? Do not find it in https://www.w3.org/ns/solid/terms

The Preferences Document

there MUST be exactly one Preferences Document

it MAY have zero or more triples with the rdfs:seeAlso predicate

If I can have an seeAlso-extended preferences file, why not linking multiple preferences files in the first place? Those could then be loaded in parallel instead of having to follow seeALso serially.

Extended Profile Documents

they MAY be accessible to public, restricted, or private audiences

Agreed, but the diagram below suggests that private parts of the extended document have to be linked from the preferences document.

if they exist, they MUST contain triples with the WebID as subject

I think it is perfectly fine when the WebID is "only" the object, e.g. like schema:Event schema:performer <webId>.

jeff-zucker commented 1 year ago

I do not get, why we need to differ between solid:ProfileDocument and foaf:PersonalProfileDocument.

Well, organizations and software clients have profile documents too. But I'm not sure we need to require either one.

there MUST be exactly one Solid WebID Document for a given WebID URI

Why that? And which of the two documents do you mean here?

I mean the WebID Document, the one that the WebID URI points directly to and which contains a solid:oidcIssuer. You can not have a WebID URI that points to more than one of those.

it MUST be able to be dereferenced as RDF from the WebID URI

I assume this is already covered by the WebID spec?

Yes, I will refer to that for this section rather than rewriting the rules.

it MUST be publicly readable

Why that? I can imagine private WebID (and respective documents) I am only sharing with my family or company. This feels like an unnecessary restriction.

A profile can be shared via a restricted or private seeAlso file. That seems more flexible in case you later decide you want some of your profile public but most of it restricted. But maybe you're right that this is not needed.

it MUST include one or more triples using the solid:oidcIssuer predicate

That's a requirement of Solid OIDC and does not need to be covered here, imho. This spec should be independent of the auth mechanism.

Yep. That's one of the things down the discussion. Remove this from the conformance rules and add it to a non-normative section saying that Solid OIDC is currently widely used and when it is used the solid:oidcIssuer predicate is required by that spec but other predicates may be required in future specs .

The Solid Profile Document (solid:ProfileDocument)

there MUST be exactly one Solid Profile Document for any given WebID URI

Same as above, why only one? Of course my WebID only resolves to one document, but every document linked via rdfs:seeAlso could also be such a document?

1) if the IdP protects the WebID document, users are not free to write multiple seeAlsos there, therefore it should point one place which can have as many seeAlsos as the user needs. 2) We don't want seeAlso's inside seeAlsos , they are avoided this way 3) using only seeAlsos without a starting point document would leave a lot of confusion about where to store things, our way says everything stems from one document. 4) We will be encouraging people to put as much as possible in the Profile document rather than seeAlsos so that many kinds of uses can skip the step of loading the seeAlso files (e.g. you just want the name or inbox, unless those are restricted, you should find them before loading seeAlsos). Loading the seeAlsos is the most potentially expensive step, and also one that can often be avoided, therefore they should be loaded last and we need the profile and preferences documents available for loading before them.

it MUST have exactly one space:preferencesFile triple

why only one? And it could be elsewhere in the extended profile, not necessarily in the "root".

Because it is designed to be an equivalent to the Profile Document - a starting place for exploring the private profile. See all the reasons above for the main profile which mostly apply here too. Also, the other way, apps need to try to load all the seeAlsos when many kinds of data may be accessible without those loads. If these were all seeAlsos coming off of the main profile, apps would need to load them all before loading the preferences file and if they are not the WebID owner, all of those seeAlso loads would be unnecessary. If you aren't the WebID owner, you make one call to the preferences file and if it fails, you're done and you don't even know the private seeAlsos exist much less try to load them.

users can choose to restrict access to their inbox, and/or storages. In that case, the triples for them SHOULD be placed in the Preferences Document for fully private resources or in a seeAlso document for restricted audiences. When there is no specific reason otherwise, the ldp:inbox and space:storage triples MUST be written in the Solid Profile Document.

I am not sure if I understand that paragraph. Perhaps it should be split down. In the end I would assume that I can place my ldp:inbox and space:storage anywhere in my extended profile document or preferences.

It's meant to say that, yes you can place them anywhere, but you shouldn't unless you have a good reason. I'll try to clarify.

it MAY have zero or more triples with the solid:community predicate

What is the meaning of that predicate? Do not find it in https://www.w3.org/ns/solid/terms

We'll have an entire section on it. It will be labeled "at risk" with text denoting that it is new. It is a term that @timbl came up with. When an app comes to my profile and sees <#me> solid:community <SomeOrganization> apps will be able to explore the type indexes of the organization so that they can show me those calendars, trackers, address books, etc. that the organization chooses to share with me.

If I can have an seeAlso-extended preferences file, why not linking multiple preferences files in the first place? Those could then be loaded in parallel instead of having to follow seeALso serially.

See above. Also other kinds of private links would go here, e.g. solid:privateTypeIndex. But mostly if all private links come from one place the app only looks in that one place and then moves on if it isn't the WebID owner whereas the other way the app would have to try to load all of the private seeAlso files, never knowing if it was meant for them until they tried.

Agreed, but the diagram below suggests that private parts of the extended document have to be linked from the preferences document.

That is correct. Everything that is meant only for the WebID owner must come out of the preferences document.

I think it is perfectly fine when the WebID is "only" the object, e.g. like schema:Event schema:performer <webId>.

That's an interesting case you propose though, I wonder if something like that would go in the type indexes instead.

I'm not sure that the objects are covered by the rdfs:seeAlso predicate which AFAIK implies that the seeAlso document contains statements with the same subject as the triple pointing to it. Wheras sameAs implies that the person in both documents is the same and therefore all statements in which they appear apply. It's one of the reasons we dropped sameAs - it could potentially lead to massive loading (e.g. entire Wikipedia pages, etc). We'll say that apps are free to use sameAs but should not expect that any other app will follow the links.

csarven commented 1 year ago

I think the main thing that needs to be clarified in the specification is the notion of "ownership" and "control", and if they are equivalent to, wilfully violating, or extending terms defined in the other specs. Everything should stem from that.

Introducing the notions of different kinds of Profile Documents comes across rather cumbersome at the moment, but that may just be how they are described/expressed.

Apply the principles and good practises from https://www.w3.org/2001/tag/doc/selfDescribingDocuments . (Also mentioned in https://solidproject.org/TR/protocol#self-describing-resources [SOLID-PROTOCOL].)

Some comments:

[Edited to remove type indexes and reorient for wider audience]

Given that IdPs

What's the definition of "IdP"? What kind of IdPs? What's the relationship between the notion of IdP and the WebID Profile spec? Former a dependency on WebID Profile? Why?

may wish to restrict how WebID Documents behave, including limiting the ability of the WebID owner to write to the document

What's the definition of "WebID owner"?

Why are the "owners" restricted to write to the document?

Who can write to the document?

Who has the ultimate authority of a WebID URI?

What's the relationship between the WebID "owner" and https://www.w3.org/TR/webarch/#uri-ownership [AWWW]?

As per https://www.w3.org/2005/Incubator/webid/spec/identity/ [WebID]:

The WebID HTTP URI must be one that dereferences to a document the user controls.

If a user may not ultimately "own" the WebID URI and/or "control" the dereferenced document (as per WebID, AWWW), then what are the differences in Solid WebID Profile?

we need to support the ESS-like model in which the WebID document is not the same document as the Profile document.

What is a "WebID document" and a "Profile document"?

If we proceed as I've outlined below, we would have two shapes which can occur in one document or in two documents. In the NSS-like instance where the same document is both the WebID document and the Profile document, it would need to conform to both shapes. In the ESS-like instance the WebID Document could be very minimal and the Solid Profile Document would conform to the same shape as all other Solid Profile Documents.

I also propose two new terms a solid:ProfileDocument class and a solid:profileDocument predicate. We can add a note that, for backward compatibility, developers may wish to also check for the foaf:primaryTopicOf and foaf:PersonalProfileDocument.

What's the definition of solid:ProfileDocument and solid:profileDocument (and relationship to foaf:primaryTopicOf and foaf:PersonalProfileDocument)?

A general comment on the requirement level keywords: they may not be needed, e.g. "MAY have zero or more" can simply be "have zero or more".

Solid Profile Data Model Conformance

The Solid WebID Document

  • there MUST be exactly one Solid WebID Document for a given WebID URI

Use a different term than "exactly" and see whether it needs to be said? What happens if there is 0 or more than 1?

  • it MUST be able to be dereferenced as RDF from the WebID URI

Already defined in [WebID]:

A WebID Profile is an RDF document

  • it MUST be publicly readable

Okay.

  • it MUST include one or more triples using the solid:oidcIssuer predicate

The WebID owner may not necessarily use an OIDC Issuer. It may be more flexible to express this in terms of when the WebID owner uses an OpenID provider.

  • it MUST either label itself as a Solid Profile Document using a triple equivalent to <> a solid:ProifleDocument. or include a pointer to a Solid Profile Document using a triple equivalent to <?WebID> solid:profileDocument <?SolidProfileDocument>..

Express in terms of "type" or "kind" instead of "label".

See also : WebID Specification.

The Solid Profile Document (solid:ProfileDocument)

  • there MUST be exactly one Solid Profile Document for any given WebID URI
  • it MUST have exactly one triple in the form <> a solid:ProfileDocument

Same comments as earlier.

  • it MUST have exactly one space:preferencesFile triple
  • it MUST be writable by the WebID owner or those they designate

Clarify delegation. Perhaps acl:delegate.

  • it MUST be publicly readable

Okay... so all Solid Profile Documents are read-only?

  • it SHOULD have exactly one ldp:inbox triple
  • it SHOULD have one or more space:storage triples

Perhaps to be expressed similar to solid:oidcIssuer in that "when WebID owner wnats to.."

  • users can choose to restrict access to their inbox, and/or storages. In that case, the triples for them SHOULD be placed in the Preferences Document for fully private resources or in a seeAlso document for restricted audiences. When there is no specific reason otherwise, the ldp:inbox and space:storage triples MUST be written in the Solid Profile Document.

Restricting access to inbox/storage need not be said. That is a given (as with any resource). Perhaps this needs to be clarified in terms of visibility, observability, discoverability, linkability, authorization...?

Perhaps just the wording but it seems to create an either or situation. But it should be possible for WebID owner to do all of those things at the same time.

  • it MAY have zero or more triples with the solid:community predicate
  • it MAY have zero or more triples with the rdfs:seeAlso predicate

Okay..

  • it MAY be the same document as the WebID Document or a separate Document. In the case in which the Solid Profile Document and the Solid WebID Document are the same, the document MUST conform to the rules listed above for both types of documents.

This is confusing.

The Preferences Document (space:preferencesFile)

  • there MUST be exactly one Preferences Document
  • it MUST be writable by the WebID owner or those they designate

This is a given. Perhaps the assumption that any resources that's being described is/may be subject to authorization should be stated earlier so that these statements need not be said.

  • it MUST NOT be readable or writable by anyone other than the WebID owner or those they designate

Need not be said? Doesn't that essentially cover all possibilities?

  • it MAY have zero or more triples with the rdfs:seeAlso predicate

Okay..

Extended Profile Documents (rdfs:seeAlso)

  • there MAY be zero of more extended profile documents

Okay..

  • they MAY be accessible to public, restricted, or private audiences

Need not be said?

  • if they exist, they MUST contain triples with the WebID as subject

Okay. But perhaps not solely.

jeff-zucker commented 1 year ago

Why are the "owners" restricted to write to the document?

I should clarify - owners can write to a WebID document even in ESS. But they have to use a server-script that does not follow the Solid Protocol. So they still own it in the sense of being able to write to it, just not via a Solid app.

Who has the ultimate authority of a WebID URI?

Issuers and users have different parts of the authority. Do we need to define that here?

What's the definition of "WebID owner"? Who can write to the document? What's the relationship between the WebID "owner" and https://www.w3.org/TR/webarch/#uri-ownership [AWWW]?

These issues will all need to be addressed. The text here is not meant to be fully explanatory, rather to spark discussion. We definitely need to define (or in most cases refer to other specs' definitions for) the ideas of WebID, ownership, control, and delegation. The section on the WebID Document will refer to the WebID spec and not change or require anything other than the solid:profileDocument predicate.

As per https://www.w3.org/2005/Incubator/webid/spec/identity/ [WebID]:

The WebID HTTP URI must be one that dereferences to a document the user controls.

If a user may not ultimately "own" the WebID URI and/or "control" the dereferenced document (as per WebID, AWWW), then what are the differences in Solid WebID Profile?

A user can control a WebID Document in ESS using server-provided access that does not follow the Solid Protocol. So the user does have control but a Solid app operating on their behalf does not because it is not on a Solid server and does not need to conform to the Solid Protocol. So I don't think our spec adds any special rules or requirements on top of the WebID Spec other than the solid:solidProfileDocument triple.

What is a "WebID document" and a "Profile document"?

If you can't answer that from the conformance rules, I'm at a loss to explain, let's chat if you are still unclear on this.

What's the definition of ... solid:profileDocument (and relationship to foaf:primaryTopicOf )?

A predicate whose subject is a WebID and whose object is a Solid Profile Document as defined in the rules here listed.

A general comment on the requirement level keywords: they may not be needed, e.g. "MAY have zero or more" can simply be "have zero or more". ... Use a different term than "exactly" and see whether it needs to be said? What happens if there is 0 or more than 1?

Noted! Will drop the unneeded MAYs and the exactlys.

Already defined in [WebID]:

Yep, already edited to point there.

The WebID owner may not necessarily use an OIDC Issuer.

Right, edited to remove this from the rules.

  • it MUST be writable by the WebID owner or those they designate

Clarify delegation. Perhaps acl:delegate.

TBD.

  • it MUST be publicly readable

Okay... so all Solid Profile Documents are read-only?

No, they must be writable by their owners and readable by the public. Any other permissions or lack of them are permitted.

  • it SHOULD have exactly one ldp:inbox triple
  • it SHOULD have one or more space:storage triples

Perhaps to be expressed similar to solid:oidcIssuer in that "when WebID owner wnats to.."

Yes, good idea.

Restricting access to inbox/storage need not be said. That is a given (as with any resource). Perhaps this needs to be clarified in terms of visibility, observability, discoverability, linkability, authorization...?

Yes, good point, it's not about whether the inbox is private it's about whether the triple describing the location of the inbox is private.

  • it MAY be the same document as the WebID Document or a separate Document. In the case in which the Solid Profile Document and the Solid WebID Document are the same, the document MUST conform to the rules listed above for both types of documents.

This is confusing.

I'm open to better way to say it. If the WebID dereferences directly to this document, it needs to follow the rules of both documents. If the WebID dereferences to a WebID Document that points to this document, this document only needs to conform to the rules for a Solid Profile Document but not the rules for both documents.

  • it MUST be writable by the WebID owner or those they designate

This is a given.

Um, yep, I should remove that line.

  • it MUST NOT be readable or writable by anyone other than the WebID owner or those they designate

Need not be said? Doesn't that essentially cover all possibilities?

It needs to be said for app developers who are creating a preferencesFile when none exists - they need to know the access rules to place on it.

  • they MAY be accessible to public, restricted, or private audiences

Need not be said?

Perhaps move it to a note.

  • if they exist, they MUST contain triples with the WebID as subject

Okay. But perhaps not solely.

Right. I edited the top post to reflect this.

jeff-zucker commented 1 year ago

@RubenVerborgh wrote

I cannot stop anyone from creating a document for any given WebID URI. [EDIT : previously quoted wrong part of the comment]

We will have prior text describing that this spec is aimed at app developers; that the conformance rules are meant to assist them in learning what to expect in a well-formed profile; and how to create a well-formed profile if they are an app able to do that. Since servers vary, and users can edit, delete, and change access on any resource, there is no guarantee that an app will have access to a well-formed profile. In that case, fixer apps can offer to make the profile well-formed and can do so by following the rules listed here.

jeff-zucker commented 1 year ago

@RubenVerborgh yes, understood. Every requirement will be marked both in the text and in RDFa as to the both Who and What. Some of the things I've listed here will end up as non-normative text. Anything that isn't will have a specific subject and object.

That specific MUST, they can never implement. It's an impossibility due to the way it is written.

Sorry, which MUST? If you mean that fixer apps can offer to fix - that will be totally optional.

jeff-zucker commented 1 year ago

@RubenVerborgh thanks, didn't know if you meant an additional point.

All requirements will have agents. The description of the Solid WebID Document will be left to the WebID spec with the exception of some non-normative text and the requirement for the solid:solidProfile predicate.

NoelDeMartin commented 1 year ago

I just went through the entire discussion, thanks @jeff-zucker and everyone else involved in the efforts thus far :).

Here's my five cents:

the WebID owner or those they designate

This is mentioned in a couple of places, but I'm not sure what it means.

Since it's written with an OR, instead of an AND, does it mean that it would be possible that I am the owner of a WebID and I'm not able to write in my own profile?

it MUST be publicly readable [Note : we're not sure, thoughts?]

Yes, I think it should be publicly readable.

I've read @angelo-v's comment on private WebIDs, but I think in that case the WebID Document and Profile Document should only contain the bare minimum to make them valid. All additional information can be in the Restricted Extended Profile.

All of which yields this updated diagram

Looking at that diagram, I understand how it works but I think some of the names are confusing. Why is one called "Preferences Document" and then "Private Extended Profile Document(s)"? Wouldn't it be possible to call everything Profile Document(s)? Then we could have:

I guess in this case, it'd make more sense to use solid:privateProfile instead of space:preferencesFile (and we can still mention it for backwards compatibility as we're doing with foaf:PersonalProfileDocument).

[@ThisIsMissEm] Perhaps also keep in mind that nothing in the spec says that a WebID must be a solid dataset or writable resource; it could just be a turtle file on an nginx webserver.

This makes me wonder, in that case, I suppose the WebID Document will not respond to Accept headers for things like JSON-LD, right?

I suppose in that case, it should be explicitly noted that WebIDs only successfully return Turtle. All other RDF formats should just be up to each server's implementation.

Looking at the Solid spec, it seems like at least JSON-LD is mandatory for Solid documents.

[@jeff-zucker] there is no guarantee that an app will have access to a well-formed profile. In that case, fixer apps can offer to make the profile well-formed and can do so by following the rules listed here.

I'm not sure what you mean with this. I know that in practice there could be malformed profiles in the wild. But in that case, aren't they violating the spec and it's not an app's responsability to fix them?

I guess you're just mentioning it because it would be nice if those fixer apps could exist, so it's important for the spec to allow for that. But I guess it's to be expected that apps don't work properly if there is something wrong with the profile, right?

There were also a couple of mentions about caching in order to mitigate the issue of making many requests (@Otto-AA, @smessie).

I've recently implemented this in an app, and there is a problem that maybe could be addressed by this spec (should I open an issue to discuss it?).

The gist of the problem is that caching the profile is great, but then we're faced with the issue of deciding when to invalidate this cache. For things like an avatar or display username it may not be too important, but when it comes to adding things on a type index or additional storages, it's important that apps are aware of the new information.

I was thinking on adding some advanced setting in my app to force it, but it would be great if the Profile Document included a triple indicating the last time anything in the profile was modified. That way, I could just do one request and know if I need to load the entire chain of documents again.

This is similar to an ongoing discussion in the main Solid spec: https://github.com/solid/specification/issues/227#issuecomment-773945439

jeff-zucker commented 1 year ago

the WebID owner or those they designate

This is mentioned in a couple of places, but I'm not sure what it means.

Definitely I was unclear. We will specify this much more completely and the word I meant was delegate. We will point to a spec (acl I believe) that defines delegation. Basically it covers situations such as a child delegating ownership to a parent.

Looking at that diagram, I understand how it works but I think some of the names are confusing. Why is one called "Preferences Document" and then "Private Extended Profile Document(s)"? Wouldn't it be possible to call everything Profile Document(s)? Then we could have:

  • WebID Document
  • Public Profile Document
  • Private Profile Document
  • Public Extended Profile Document(s)
  • Restricted Extended Profile Document(s)
  • Private Extended Profile Document(s)

I guess in this case, it'd make more sense to use solid:privateProfile instead of space:preferencesFile (and we can still mention it for backwards compatibility as we're doing with foaf:PersonalProfileDocument).

Hmm, I like that a lot. We'll discuss.

[@ThisIsMissEm] Perhaps also keep in mind that nothing in the spec says that a WebID must be a solid dataset or writable resource; it could just be a turtle file on an nginx webserver.

This makes me wonder, in that case, I suppose the WebID Document will not respond to Accept headers for things like JSON-LD, right? I suppose in that case, it should be explicitly noted that WebIDs only successfully return Turtle. All other RDF formats should just be up to each server's implementation. Looking at the Solid spec, it seems like at least JSON-LD is mandatory for Solid documents.

Yes, but the WebID Document doesn't have to follow the Solid spec - it is not necessarily on a Solid resource server. The Solid Specs are not relevant to all WebID Documents, That said, the WebID spec says turtle is a MUST and other formats are a MAY so yes, we should warn developers.

[@jeff-zucker] there is no guarantee that an app will have access to a well-formed profile. In that case, fixer apps can offer to make the profile well-formed and can do so by following the rules listed here.

I'm not sure what you mean with this. I know that in practice there could be malformed profiles in the wild. But in that case, aren't they violating the spec and it's not an app's responsability to fix them?

It is not an app's responsibility to fix a profile but neither is it anyone elses. There is no spec telling servers that they must create profiles in a given manner and @timbl has been very clear that this spec should not be aimed at servers and that apps ARE the only part of the ecosystem that can ensure valid profiles. This is why he and Timea have been changing the discovery code in SolidOS to write missing parts of the profile.

I guess you're just mentioning it because it would be nice if those fixer apps could exist, so it's important for the spec to allow for that. But I guess it's to be expected that apps don't work properly if there is something wrong with the profile, right?

They will exist as soon as the latest mashlib is merged. :-) And yes, it's an important part of the spec to not only say apps can do that but to also describe how to do it if able and willing. And yes, if the one of the pieces of a Profile mentioned in the spec is missing, the profile can be considered broken. Apps might be able to get what they need from even a broken profile (depending on how it is broken) but there is no guarantee..

There were also a couple of mentions about caching in order to mitigate the issue of making many requests (@Otto-AA, @smessie).

I've recently implemented this in an app, and there is a problem that maybe could be addressed by this spec (should I open an issue to discuss it?).

Yes please.

The gist of the problem is that caching the profile is great, but then we're faced with the issue of deciding when to invalidate this cache. For things like an avatar or display username it may not be too important, but when it comes to adding things on a type index or additional storages, it's important that apps are aware of the new information.

I was thinking on adding some advanced setting in my app to force it, but it would be great if the Profile Document included a triple indicating the last time anything in the profile was modified. That way, I could just do one request and know if I need to load the entire chain of documents again.

This is similar to an ongoing discussion in the main Solid spec: solid/specification#227 (comment)

Interesting idea, please raise a separate issue and we'll discuss.

angelo-v commented 1 year ago

it MUST be publicly readable [Note : we're not sure, thoughts?]

Yes, I think it should be publicly readable.

I've read @angelo-v's comment on private WebIDs, but I think in that case the WebID Document and Profile Document should only contain the bare minimum to make them valid. All additional information can be in the Restricted Extended Profile.

What is the point in having a public profile, that does not contain any public data? And why should we enforce organizations to publish all their employees WebIDs? Why is it important that WebID documents are publically readable? Even WebIDs that are only reachable within an intranet should work quite fine.

jeff-zucker commented 1 year ago

The Editors are hotly debating the topic of the privacy of the Solid Profile Document (the main profile document, not all the others), so thanks much @angelo-v and @NoelDeMartin for chiming in. We will previously have defined "private" as accessible only by the WebID owner.

why should we enforce organizations to publish all their employees WebIDs?

Whoa, how does that follow from having the Solid Profile Document be publicly readable? We are NOT talking about making the entire set of profile documents readable, only the main Solid Profile Document. The employee WebIDs belong in a seeAlso document restricted to HR or to whomever the organization decides, they should never go in the main Profile Document.

And this illustrates the answer as to why there should be a public main Profile Document with no public data. If the organization puts the WebIDs in a restricted seeAlso file and the main Profile Document only contains a pointer to that file and the organization later decides they want to make some information public, they can put the public information in the previously almost empty Profile Document and leave the employee WebIDs in the protected document and they are done. If they start by putting the WebIDs in a private main Profile Document and then want to present some public information, they'd need to move the private material out of the Profile Document, create and create access rules for a different document, change the access rules for the Profile Document. Why not start with proper structure and put restricted things in places meant to be restricted?

jeff-zucker commented 1 year ago

I guess the case of an organization that only ever wants to present information to its members and will never have any public access is somewhat different. I still argue that it should follow the principles of putting restricted materials in restricted seeAlso files - that way apps will be able to look for the same structure for that organization as everywhere else.

jeff-zucker commented 1 year ago

I especially am against servers "protecting" their users by defaulting to a private main Profile Document - this would leave the user with a very messy task if they later decide to make parts of it public. If the server wants to default to a private Profile (not Profile Document) it should do so by putting all information in private seeAlso file. I am all in favor of defaulting to a private Profile. I am against defaulting to a private Profile Document.

jeff-zucker commented 1 year ago

Users should have a very clear picture - if I put this thing here, it is Public, if I put it there it is Private, and if I put it in a place I restrict, it is Restricted. They should know - if I put something in the main Solid Profile, it is Public, so if I want it Restricted or Private, I need to put it somewhere else.

jeff-zucker commented 1 year ago

[EDITED to expand on the model]

An application should create and expect this

Private Resources (only the WebID owner)

Public Resources (anyone)

Restricted Resources (those given consent by the WebID owner)

This not only makes it very clear where differently consented resources should go, but also gives apps a way to prioritize resources - reading the Profile Document and Preferences Document is likely to answer most questions and loading of the (possibly multiple) Extended Documents is only needed for special circumstances. This makes the easy things easy and the hard things possible.

jeff-zucker commented 1 year ago

I phrased the previous comment as coming from the Editors. It is my opinion, only. Some other Editors are not in favor of recommending a public main Profile Document. Nothing is written in stone or even invisible ink.

jeff-zucker commented 1 year ago

I think that, fundamentally, dividing information between public and private is flawed

I have to wonder then how Solid in general and this spec in particular can address the goal that @timbl has set stated : "provide a gradient of intimacy between the private and the public".

we are basically hitting the limits of document-orientation and access control

There are certainly going to be different solutions in the future, but documents and access control are what we have now.

A simple but crucial pet peeve is a piece of information as simple as a person's name. I want my banking app to see my given and family name. I want my dating app to only see my given name. So which information goes in my profile document?

Your family name triple would go in a see:Also document permissioned to only allow your banking app and others you want to know it. Your given name triple would go in the main profile document if you want everyone to know it, or, if that is also for a restricted audience, in a see:Also document permissioned to allow only your banking app, your dating app, and others you want to know it. In that latter case, neither triple would be in the main profile document.

jeff-zucker commented 1 year ago

@RubenVerborgh lots of food for thought in your posts. May I ask if you see any value at all in having a Profile spec? What would it clarify if it can't clarify the WebID Document (because it might not be on a Solid resource server) and it can't clarify permissions (if we accept your reasoning), what would it say? Go to the WebID URI and keep opening things that say they are profile documents until you find what you need. I'm not being rhetorical, is that all we can tell developers?