Create best practices for profile predicates
jeff-zucker opened this issue · 24 comments
The specs do not mandate any triples in a profile except those related to OIDC. That means that triples using predicates like ldp:inbox, pim:storage, pim:preferencesFile, solid:account, solid:*typeIndex are optional and the specs, AFAIK, have nothing to say about them in relation to the profile. I believe that there should be a non-normative best practices section describing recommended uses of these predicates and descriptions of some of the reasons why a user might want to include or omit them.
These predicates would remain optional, so apps would need a fallback if they are not found. But an app could also have a "first port of call", a place that is easy to find (we know the webId so can find it's profile) and likely (though not certain) to find the scents needed to follow its nose.
Due to the use of these predicates in NSS profile provisioning and in the SolidOS databrowser discovery, there is already a defacto convention in use. But I believe we should have some more official best practices. To me it is an open question as to whether these should be for apps and users only, or whether there should be some aimed at pod providers.
The typeIndexes are probably the most controversial as the Interoperability Panel will be finalizing a more robust method soonish. I'm not sure if this means that there be no best practice for the existing typeIndexes or whether we can support them as an alternate method for those not requiring the full power of the coming Data Registraion methods.
Do others agree this kind of best-practice document is a need? If so, what's the best way to go about tackling this? In this panel or in some other team?
See also this related forum discussion.
We already had something like that here https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md
I like that document. I propose that we take it as a basis and discuss how it should be changed and where it should be located.
At first glance, I see these changes needed :
- describe solid:oidcIssuer and other OIDC predicates
- omit the TLS predicates
- Add some web-monitzation predicates?
- the type registry section should be either replaced by or amended to include the new Data Registration process.
- there should be an explanation of to whom the recommendations apply. For example who is responsible for "profile SHOULD point to the root storage location using pim:storage" ? I would suggest that it is the pod-provider (not the server implementer or user) who is the one who SHOULD.
Oops, the last one used a bad exampl, because another thing to change is :
- mention that the pim:storage predicate should be up to the user (opt-in? or opt-out?)
Such a document could be useful, but only if there is buy-in from most popular Solid server developers (i.e. servers that aim to specifically support Solid, rather than just LDP or whatever) that commit to adhering to them by default (even if users have the option of straying away from it). If developers cannot reasonably assume the best practices to be adhered to, they're just empty words. (Compare e.g. web developers not adopting new HTML elements until all browsers with major use supported it.)
Also, some relevant earlier discussions:
Thanks for raising this thread @jeff-zucker! This topic is one that we've devoted a lot of time working on in this panel, as it's essential for seamless interoperability.
The typeIndexes are probably the most controversial as the Interoperability Panel will be finalizing a more robust method soonish. I'm not sure if this means that there be no best practice for the existing typeIndexes or whether we can support them as an alternate method for those not requiring the full power of the coming Data Registration methods.
To provide a bit of context from the perspective of the application interoperability specification:
In the spec, we have two types of Agents:
- Social Agents which can be people like you and I, or organizations like Acme
- Applications which are created and or used by Social Agents.
The Social Agent is most pertinent to the context of this thread as it is represented in the WebID document. (Note - I've just added an issue to connect the dots with Solid-OIDC a bit more).
Lets say our Social Agent (Alice) wants to use an Application (Projectron), and Projectron needs to know where to find Projects and Tasks. This would be where we would traditionally go to typeIndexes in Solid, but we had to solve for an additional security problem - principle of least privilege. The type index design doesn't compartmentalize information between applications, and that breaks the principle of least privilege, which was one of our design goals. In a simple example, a health app or service shouldn't know anything about your finance data and vice versa.
Instead, Projectron describes the access it needs, and Alice uses her Authorization Agent to determine whether she'll give them that access. Her decision is captured as an Access Consent, and shared with Projectron as an Access Grant. The Access Grant tells Projectron exactly what access its been given, and it can proceed from there.
@justinwb thanks for your thoughts and for adding that issue. Is solid:oidcIssuer the only OIDC predicate required for the profile, or are there others?
The typeIndexes, as I said, are the most controversial. I would really appreciate it if we do not derail this entire discussion to focus on that. The preferences file and storage and other predicates are just as vital to apps in other ways and it is not appropriate to ignore them and focus only on the typeIndexes.
I do understand the need that some apps will have to not be listed along with others in the current typeIndex. I do wonder though if my recipes collection needs the same level of privacy as my bank account. Is it possible that we can support both forms of indexes with a clear warning that only one of them offers privacy? If this idea is worth discussing, let's discuss it on one of the existing issues or another issue and not cloud the discussions of the other predicates over this. If this idea isn't worth discussing, that's okay too - my main point is the other predicates.
@Vinnl wrote
Such a document could be useful, but only if there is buy-in from most popular Solid server developers
I agree, but I've gotten a lot of pushback when I say that. This is the problem I mentioned about who it is these practices should apply to. It would certainly be easiest if CSS and other server implementers had a default profile provisioned with the predicates we need. But, if that is not possible, it becomes the pod-provider's responsibility. It is dead-simple for a pod-provider to provision a CSS profile with the predicates we need.
If neither the server nor the pod-provider will accept responsibility, it becomes you and me (app and library developers) who will have to get into user's profiles and muck around extensively. That seems unsatisfactory both for the devs and for the users.
@justinwb - what predicates, if any, will be required in the profile related to the new (and very exciting and robust) alternative to typeIndes). And if not in the profile, where does one begin following one's nose?
@justinwb thanks for your thoughts and for adding that issue. Is solid:oidcIssuer the only OIDC predicate required for the profile, or are there others?
Yes for an individual's profile that's all that should be needed from that perspective
The typeIndexes, as I said, are the most controversial. I would really appreciate it if we do not derail this entire discussion to focus on that. The preferences file and storage and other predicates are just as vital to apps in other ways and it is not appropriate to ignore them and focus only on the typeIndexes.
Totally fair 🙂 And you're right, there's plenty of value in providing some specific guidance for the Identity Profile Document itself, possibly in a standalone document, that can reference other documents / specs (e.g. Solid-OIDC, Solid Protocol, Application Interoperability, etc) where necessary.
@justinwb - what predicates, if any, will be required in the profile related to the new (and very exciting and robust) alternative to typeIndes). And if not in the profile, where does one begin following one's nose?
For the profile document, this is detailed (with example) in the Social Agent section. The two key properties are a link to the individual's Authorization Agent, and a link to their Registry Set, which is only used by the Authorization Agent.
So the most important predicate for a typical application is interop:hasAuthorizationAgent, because they'll need to redirect them to whatever the object value is. The Authorization Agent will take the Application's data needs as input, and turn that into an Access Grant that the App can access to follow its nose to data. For a specific breakdown of that flow there's a nice walkthrough here.
To your specific question, the Application (e.g. Projectron) will then get a pointer to an Access Grant (stored in the Application Registration for Projectron in the data owner's pod). Projectron can then follow its nose from the Access Grant to data its been granted access to, including what scope and modes of access they have to it. Since the types are indicated by shape trees, they also know how it should be physically organized, so they'll know where to put things, and which shapes will be used to validate them.
Thanks, that clarifies a lot
there's plenty of value in providing some specific guidance for the Identity Profile Document itself, possibly in a standalone document,
I've proposed above that that document be a modification of https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md. The info you just provided will be useful in adding solid:oidcIssuer, and interop:hasAuthorizationAgent into that documentation. From an implementer's point of view "what can I expect to find in a user's profile?" is the most important question and I believe this document should be a priority. I'm willing to take an active role in making it happen if others agree.
I'd suggest to start with a modest recommendation for a profile document - like the solid-webid-profile.md. Reflecting reality would go a long way - so that'd be existing profiles in the wild and existing open applications in the wild making use of the properties and so forth. Instead of bloating the profile document right off the bat. Check with dogfooders for actual signal.
@jeff-zucker , since you're keen on getting this going, all the power to you. Go for it! I'd be happy to assist in editing, if you like.
@csarven where should this new document be located, the old one was in solid/solid-spec ?
PR to solid/specification should be fine. It'll end up at https://solidproject.org/TR/{shortname}. But hang on just a bit. I've added this issue to the next Solid Editors meeting agenda (tomorrow). Will come back with concrete steps.
@csarven - thanks I will need your help and that of the interop panel to make sure we end up with something that suits all and that has links to appropriate specs.
Did I understand you correctly that you agree with me that starting from the existing solid-webid-profile.md is a good plan? I agree with you that looking in the wild is important and that the document should not be bloated beyond the existing one other than to include the oidc and interop predicates and to clarigy to whom the various recommendations are addressed.
Minutes of the Editors meeting: https://github.com/solid/specification/blob/main/meetings/2021-10-20.md#create-best-practices-for-profile-predicates includes a RESOLUTION with group agreement that @VirginiaBalseiro @jeff-zucker @theRealImy can coedit/author the Profile document. In parallel, all have agreed to contribute. There was no particular agreement on where the work should be carried out. As noted earlier, it will eventually be PR'd to solid/specification and published in a document under TR/. (Drafting a PR there may be one simple option.)
I would suggest that the editors/authors of this upcoming document to "work independently" (but encouraged to ping people/panels as necessary), process existing documentation and issues across several repositories, take existing publishing and open applications into account, and PR the draft/final work to solid/specification.
Is there a specific place where work on WebID Document content will happen? In solid/solid-oidc#51 (comment) we have a suggestion that we shouldn't assume it being public. I think that impacts more than just Solid-OIDC and it would be good to discuss in in one place and any spec relying on WebID Document might need to address what happens if it is not public.
w3c/WebID#1 is one lower level issue.
Discuss WebID in context of where it is being used.
Create issues in solid/specification as necessary.
@elf-pavlik - The spec for the WebID document will be helmed by @VirginiaBalseiro, @theRealImy , and me. We are currently waiting for Virginia to finish up some other matters and will open a new repo when we've had a chance to meet and discuss. In the meantime, this discussion is the place. My feeling is that we will stick to the WebID documents of SocialAgents and not even touch the potential future use of WebID documents of Applications but since I haven't had a chance to discuss with the others, I can't say if that will be our policy.
Discuss WebID in context of where it is being used.
Create issues in solid/specification as necessary.
Yes but, until we have a new repo, please leave a breadcrumb here if it relates to the coming spec
For the record, the WebID Profile work is happening in https://github.com/solid/webid-profile
I suggest to close this issue then?
I think we can wait until solid/webid-profile#97 gets resolved, based on that we will know if SAI can depend on WebID Profile spec or not.
Fine with me, although in the light of "loose couplings", i.m.o. requiring a WebID Document to contain some specific triple should not entail depending on the WebID-Profile spec (it simply adds an unnecessary spec to the chain).
I see the main issue with the distinction between statements that are crucial for security from statements that can be anything, social annotations, whatever...
I think we should bring that issue directly during the Solid CG call and later decide how we plan to work on resolving it.
Given #312 SAI will only need to accommodate interop:hasAuthorizationAgent which IMO is comparable to solid:oidcIssuer. Tampering with that statements would allow malicious parties to gain full access to all the data of that social agent. To compare, changing social avatars or nicknames by a malicious party can be embarrassing but does not lead to a complete intrusion.