Proposed Conformance Model

[jeff-zucker]

[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

• it MUST either conform to the rules listed below for a Solid Profile Document or else have a triple equivalent to <?WebID> solid:profileDocument <?SolidProfileDocument>.. For backward compatibility, the predicate can be foaf:primaryTopicOf instead.

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

• there MUST be exactly one Solid Profile Document for any given WebID URI
• it MUST have exactly one space:preferencesFile triple
• it MUST be writable by the WebID owner or those they designate
• it SHOULD have exactly one ldp:inbox triple
• it SHOULD have one or more space:storage triples
• it MAY have zero or more triples with the solid:community predicate
• it MAY have zero or more triples with the rdfs:seeAlso predicate
• it can be the same document as the WebID Document or it can be 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.

The Preferences Document (space:preferencesFile)

• there MUST be exactly one Preferences Document
• it MUST be writable by the WebID owner or those they designate
• it MUST NOT be readable or writable by anyone other than the WebID owner or those they designate
• it MAY have zero or more triples with the rdfs:seeAlso predicate

Extended Profile Documents (rdfs:seeAlso)

• there MAY be zero of more extended profile documents
• they MAY be accessible to public, restricted, or private audiences

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]

All of which yields this updated diagram

[ThisIsMissEm]

@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]

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

[gibsonf1]

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

[ThisIsMissEm]

@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]

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

[jeff-zucker]

@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]

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.

[jeff-zucker]

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 <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKVJCJG5ZLJGURPZG5IIJWLV2X7JHANCNFSM56SQD3ZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[elf-pavlik]

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]

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]

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]

@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]

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]

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]

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]

@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]

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]

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]

@VirginiaBalseiro wrote

Apps should be prepared for a scenario where a WebID document is not editable and contains no links to any profile document.

I agree. Our spec can't force anything about the WebID document. I retract anything I've said so far that implies that we should.

I would recommend always asking the user (and this applies to multiple anything, like multiple Pods)

A profile isn't necessarily used by the owner so what would a visiting app run by someone other than owner do? What would be offered to them to choose from? What about bot apps that just want to read or write something? Who would be asked to choose?

you can expect that either the WebID document is editable, or it contains a link to an extended profile document, or many

Is the app responsible for opening extended profile documents inside extended profile documents? If so, when does that stop?

If the WebID document is not editable by the Solid Protocol (which is its right), and there can be many extended profile documents, but no single Solid Protocol addressable location to point to them, how does an app create a link to one of these extended profile documents other than by creating a link to an extended profile document inside another extended profile document?

[jeff-zucker]

@VirginiaBalseiro wrote :

I agree with Ruben that this spec should not revolve around how access control is applied to any resources.

I agree with that also. The recommendations I would like to see are about if access controls are applied, not how. There are really only two questions my recommendation deals with and neither depends on how permissions are handled or restricts users ability to handle differing consents.

should the information be accessible to anyone other than the profile owner?                                       
  yes ->  should the information be available to all users and all apps visiting this profile?                                                         
    yes : profile document                                                                                                                            
    no  : extended document pointed to from the profile document                                                                                      
  no -> should the information be available to all apps visiting this profile when profile owner is user?                                                                       
    yes : preferences file                                                                                                                            
    no  : extended document pointed to from the preferences file                                                                                      

[EDITED for clarity]

[jeff-zucker]

@VirginiaBalseiro wrote

this document should not make limiting requirements such as ... the profile must be private/public

I will now agree with this point. The profile document could be private/pubic/restricted as owner wants. There would hopefully be UIs to easily convert the permissions.

[jeff-zucker]

you can expect that ... the WebID document is editable

No, you can't, but a WebID document and a Solid Profile Document are not the same thing. You should, I believe, be able to expect that a Solid Profile Document is editable by the WebID owner using a Solid software of their own choosing. The idea that the owner would need to contact the Identify Provider in order to edit their own profile makes the idea of ownership meaningless. So if the WebID Document is not editable using Solid software, it is free to not point to a Profile Document or anything else it wants. But if it wants apps to interoperably connect to a Solid Profile, it needs, in my opinion, to point to a document or documents the WebID owner can edit using the Solid protocol.

[jeff-zucker]

^^ For example, it seems to me to be completely against the Solid philosophy that the Identity Provider, without my consent, makes my storages visible to the world and does not allow Solid apps I choose to add, remove, or change the visibility of storages. Those things, to me mean I do not own my own profile.

[NoelDeMartin]

Thanks @jeff, I opened a follow up about the caching in #47

[@angelo-v] What is the point in having a public profile, that does not contain any public data?

[@RubenVerborgh] the whole design is starting to be based on a permissions model, whereas permissions are supposed to be orthogonal in Solid.

[@VirginiaBalseiro] I agree with Ruben that this spec should not revolve around how access control is applied to any resources.

Although I agree with the general idea that permissions shouldn't be tackled heavily in this spec, I still think it's important to set clear guidelines for what apps can expect from a WebID.

In particular, I want to at least know whether a url is a WebID or a random url from the internet. If a WebID is not publicly-readable and I get an error response, I don't know if that's because the WebID is private or it just isn't a WebID.

This concern arises from the UX difficulty we discussed in the forum. TLDR: I can't be sure if what users introduce when logging in is a WebID or an issue provider url or what. So in my apps, I try to search for a valid WebID and get the issue provider from there. If I can't, I just use whatever they typed as the issue provider.

Having that into account, I think it's useful that WebIDs are public even if the only public information is that they are indeed a WebID and what issue provider to use.

[@VirginiaBalseiro] To take the above question by Jeff as an example, what should an app do if there is a huge number of profiles, should it follow all… I would recommend always asking the user (and this applies to multiple anything, like multiple Pods). “We found X amount of profiles, pick one for this thing you are trying to do/using this app”

As I'm understanding this spec, all profile documents are conceptually part of the same profile, they are just separated in order to have different permissions, reduce the number of requests, or any other reasons.

So the idea of querying all documents or not is just an implementation detail to improve performance, but I don't think it's a problem a user should be concerned about.

[jeff-zucker]

I still think it's important to set clear guidelines for what apps can expect from a WebID.
In particular, I want to at least know whether a url is a WebID or a random url from the internet.

The WebID Document is defined in the WebID spec which says in a non-normative section "A WebID Profile is a public document". The Solid-OIDC spec raises that as an issue but does not definitively say that a Solid-OIDC compliant WebID Document must be public. If you are interested in ensuring a public WebID document you should contribute to that spec : https://solidproject.org/TR/oidc#oidc-issuer-discovery or to the WebID spec.

So the question of whether the WebID Document is public will not be decided in this current spec. What we will have to decide on is whether, when the WebID Document is different from the Solid Profile Document and only points to that document whether that pointed to document, the Solid Profile Document, is public. The consensus seems to be that we should not specify that.

[jeff-zucker]

@NoelDeMartin here are the definitions I would like to use :

From the WebID Specification : "A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.)."

From the WebID Specification : "A WebID Profile Document is an RDF document which uniquely describes the Agent denoted by the WebID in relation to that WebID."

Proposed by me : "A Solid Profile is a set of WebID Profile Documents that are readable and writable using methods described in Solid Protocol. The starting point of the Profile can be dereferenced directly from the WebID URI if that document is accessible via the Solid Protocol, or can be indirectly dereferenced by finding a solid:profileDocument triple in the document the WebID URI dereferences to."

Adapted by me from Solid Protocol - "A WebID owner is a person or a social entity that is considered to have the rights and responsibilities of a WebID and its associated Solid Profile. An owner is identified by a URI, and implicitly has control over all data in the Solid Profile associated with that URI."

[timea-solid]

This discussion clearly shows the hard line the editors need to walk between What is possible now with the Solid Profile and What we want the Solid Profile to be in the future. Initially, we set out to write down how it is right now so that dev have an easier time just focusing on what they love: code.

As a result, we should take a step back and leave some things as they are -> meaning: link to the location in the other specs where you find more information. For example link to: "The Solid-OIDC spec raises that as an issue but does not definitively say that a Solid-OIDC compliant WebID Document must be public." This is something we already realized we need to do in more places of this spec. We can take this discussion point in the weekly meetings because it touches on the goal of the spec.

As for the topic itself: my wish is to have in the future a so-called triple level privacy control, case in which you can have only one Solid Profile that can have all info and control the user wants/needs. The 'possibility' should stay open after this spec. (As an example: we decoupled type indexes from WebID to make sure we don't stop progress on Solid indexes.)

[jeff-zucker]

@timea-solid - I agree that we should, as much as possible, depend on existing specs and not duplicate their work. We should talk about the WebID Profile Document and OIDC non-normatively as part of the discovery process but not make any normative statements about them.

I also agree that the future is permissioned triples and that our spec absolutely should not do anything that would impede the development or deployment of permissioned triples or other future developments. OTOH, when permissioned triples are available, this spec will need to be changed. We can't possibly write a spec for permissioned triples now. And when will permissioned triples be available? (one year? five years?). I think it would be a disaster to have no profile spec between now and then. Is document permission messy and should be replaced ? Yes, definitely. Is it what we have to work with today? Yes.

To me the most important parts about the profile are

1. the Solid Profile should be modifiable by solid apps of the user's choosing and totally under the WebID owner's control (see my proposed definitions) . The Identity Provider is welcome to maintain control over the document the WebID URI dereferences to for their own purposes (such as oidcIssuer) when it is located on their own servers rather than on a Resource Server, but it can not claim that that document is a Solid Profile. It isn't, it points to a Solid Profile. Otherwise apps can not modify profiles and apps are the point in the ecosystem that need to modify profiles. Today we have a server putting our storages in public view without our permission, what is to stop a server from putting our name and passport number in the WebID document and make us make requests to them to change it? If servers rather than apps determine the shape of profiles and we can't aim a specification at servers to control that process, that means profiles are irrevocably living in the wild west where each Identity Provider gets to decide what a Solid Profile looks like. In my opinion, the server is free to add other features, but it can not do so by interfering with a user's ownership of their own profile and all of the data in it.

2. There should be a clear way for users and app developers to know where to put and look for differently permissioned materials. It should, as much as possible, support existing practice. SolidOS and many other apps are designed to work within the document permissioning system as outlined in my proposal which is itself based on the previous attempt at the webid-profile specification which was all apps have had to go by until now. I am not in favor of telling all of those apps, oh forget about that, just put stuff where you want to. I won't repeat myself on this, I think this sums up my view on permissioning.

3. The profile should, as much as possible, be designed to minimize document loads.

[jeff-zucker]

@timea-solid - in response to your mention of triple-level permissioning, I said "We can't possibly write a spec for permissioned triples now." but I now believe I am wrong about that. We can say an app writing or repairing a profile on a server that supports triple-level permissioning should, when possible put all triples directly in the Solid Profile Document but may, if it wishes, follow the document model we propose. Apps on servers that only support document level permissioning should follow the recommendations we propose for writing documents. Apps reading a profile on either type of server should read the Solid Profile Document and if that doesn't tell them what they need to know, follow the document recommendations we make to load and query. That seems to me to make our spec work with either kind of permissioning.

[jeff-zucker]

I believe Trinpod has already implemented triple-level permissioning. @gibsonf1 would the paragraph above this work for you?

[csarven]

re Editor Role:

The editor is expected to apply the consensus decisions of the Group. The editor is not expected to have all the responsibilities of the author or rights to matters which the Group does not explicitly decide. In practise, there is leeway. Editors need to practise egoless writing and they can be influential voices in Group deliberations.

(I'll look into adding something along these lines to CONTRIBUTING.md.)

---

re Orthogonality:

It is expected that specifications are kept orthogonal ( https://www.w3.org/TR/webarch/#orthogonal-specs ) and overlapping features are clearly indicated: https://solidproject.org/TR/protocol#introduction .

The WebID Profile specification is deemed to focus on identity - attached data towards presenting an agent in different contexts - and discovery, without venturing too far into identification, authentication, authorization, or modifying abstractions described elsewhere.

---

re Profile

https://gitter.im/solid/webid-profile?at=6310b75fd020d223d3181b8f :

Clarify how a profile is a presentation of an agent.
whether an agent can have different profiles and what their relationships may be..
"Extended profile" is a bit of plumbing (but essentially about the same identity). It is an answer for the need to distribute information into different resources for different reasons, access privileges being one.

To define:

• https://solid.github.io/webid-profile/#solid-profile
• https://solid.github.io/webid-profile/#extended-profile

To introduce, reuse, and clarify relationship:

re "owner", GOTO #40 (comment)

re "agent": The SOLID-PROTOCOL defines "agent" https://solidproject.org/TR/protocol#agent as:

An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [WEBID].

---

re Authentication

Clarify the abstractions involving "Identity Provider".

Consider the following for a moment: if it is deemed that a WebID Profile Document may not necessarily be a resource available from a Solid server, could the same kind of assumption not be made about a "provider" (or even Solid-OIDC in particular)? 5+ years ago we would a similar consideration could've been made when WebID-TLS was the focus for authentication.

---

re WebID Profile Document Access Privileges:

The intended access privileges about WebID Profile Documents is clarified in w3c/WebID#7 ( as per w3c/WebID#1 ) in that the WebID 1.0 specification does not set a constraint - documents can be public or protected, and they may contain public or private information.

[jeff-zucker]

re Editor Role:

The editor is expected to apply the consensus decisions of the Group.

Not sure why you're mentioning that here, but I've tried to speak only for myself and have clarified that several times in the discussion. The top posting will try to reflect the group consensus, not my opinion and other Editors are free to edit it.

re Orthogonality:

I agree entirely. We should not redefine anything in the WebID or Solid-OIDC and should conform to previous specs except in the few case where we are introducing something new.

The WebID Profile specification is deemed to focus on identity - attached data towards presenting an agent in different contexts - and discovery, without venturing too far into identification, authentication, authorization, or modifying abstractions described elsewhere.

Yes, agree, this spec should focus on presentation of identity and on discovery, and refer to other specs for identification, authentication, and authorization.

Clarify how a profile is a presentation of an agent.
whether an agent can have different profiles and what their relationships may be..

Absolutely. This is a very important step, I agree. I already have a number of use case scenarios but there should also be an overview.

To define:

• https://solid.github.io/webid-profile/#solid-profile
• https://solid.github.io/webid-profile/#extended-profile

Yes.

To introduce, reuse, and clarify relationship:

re "owner", GOTO #40 (comment)

re "agent":

Yes point to Protocol and WebID for this.

re Authentication

Clarify the abstractions involving "Identity Provider".

I think we can skip much mention of them. But yes, if we use the term we should define it.

re WebID Profile Document Access Privileges:

The intended access privileges about WebID Profile Documents is clarified in w3c/WebID#7 ( as per w3c/WebID#1 ) in that the WebID 1.0 specification does not set a constraint - documents can be public or protected, and they may contain public or private information.

Agree, we should not place requirements on the permissions on a WebID/Solid Profile Document.

[elf-pavlik]

it SHOULD have one or more space:storage triples

I raised specific a issue about space:storage #51

I see it similar to solid:oidcIssuer conversation which led to:

@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.

Solid Application Interoperability does NOT use space:storage at all. Instead, as I explain in #51 it defines two distinct paths. One for Authorization Agent and the second for other Applications (TL;DR go to Authorization Agent so that the user can authorize your access first, since even the discovery is limited to just what that app access).

I think that whatever (mini)spec relies on space:storage for discovery, and however it takes authorization into account (if at all), it should extend Solid Profile Spec in the same way SAI will be extending it.

If more than one discovery specs rely on that predicate, it might be justified to propose it up the spec chain, I don't think this is the case for space:storage.

---

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

I still think this would be the cleanest approach for documenting what can be expected in Solid Profiles without adding:

it SHOULD have one or more space:storage triples

Just to potentially realize a year or two later that SHOULD NOT would have been more appropriate.

[jeff-zucker]

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

An interesting idea, we'll discuss.

it SHOULD have one or more space:storage triples

That statement will not occur in isolation, rather will occur in the context of a description of why a person might or might not want their storage(s) findable.

[jeff-zucker]

Closing this issue. It should have been a discussion rather than an issue. Many of the points here have been taken up in other issues and there is no particular proposal in this issue which needs to be acted on. However, useful discussion for historical purposes.

[timbl]

If you close this as the points have been taken up in other issues, please link to this issues.

[jeff-zucker]

@timbl - My understanding is that @VirginiaBalseiro is working on a new set of conformance rules (see #89) and I did not feel it would be helpful to bring up issues until those are available for review. That way we can start from a review of what she proposes rather than with this issue which became muddled. If her conformance rules don't address my concerns, I will certainly raise the issues again.