Alignment between FAIR Protocol, Moderation Spec, Business Rules, & Ozone Platform

[toderash]

Overview:

The Moderation Spec and the Protocol are apparently out of sync, and need some adjustment to align well enough to implement the trust signals portion of the moderation (labelling) spec and to fully address threat/risk mitigation for the complete supply chain as required by business rules for potential stakeholders before they can adopt FAIR.

Terms:

To clarify some of the terms used here for things which may be used inconsistently within FAIR,

• "Node" could be anything connected to the FAIR network/ecosystem that uses the FAIR protocol (i.e., it's a non-specific collective term for Aggregators, Repositories, and Client/Installers.
• "Client/Installer" refers primarily (for now) to the FAIR Plugin, AspireExplorer, and AspireUpdate; generally, software used to browse, download, or install packages.
• "Author" is the creator of or contributor to a package, which may have multiple authors. By default, the author holds the copyright, unless it has been assigned to a Publisher.
• "Publisher" refers to the entity which presents the package for publication & download. A publisher may also be an author and/or operate a Repository to distribute packages. A publisher may be a vendor if a financial transaction is involved, but the broader term is preferred. A commercial plugin like Yoast or Elementor, a theme shop like Elegant Themes, and organizations like the FAIR Web Foundation or Automattic would all be Publishers.
• "Labeller" refers to what is elsewhere described as a moderation service. Labels applied as described under the Moderation Specification (colloquially here, "mod spec") may or may not carry the connotation of content moderation. Since these may present simple neutral descriptors, I'm using the neutral term derived from "Label", which the mod spec describes as its basic mechanism.
• "Trust Signal" refers collectively to specific indicators of authenticity, security, identity, or other factors used to establish trust in an entity or package within the federated network. This is a helpful descriptor for the Labels applied by the Labeller which FAIR plans to operate as a required service for all federated nodes, and helps make clear both its scope and intent.
• "Business Rules" in traditional software development (if not in webdev) these are a set of requirements determined by business operations, which a software development project must support and enforce reliably in its final implementation. These are operational rather than technical in nature, but must be resolved by the technical solution the software delivers.

The Issue:

1. Protocol Support for Moderation Spec

In discussion with @rmccue, he indicated that the protocol would need significant changes in order to support the concept of Publishers as an entity, though the specific changes required have not been identified. The protocol does not have (or require) that a package be linked to its author, whether an individual or an organization. From a technical standpoint, trust centers on the package (or its DID). The protocol does not require an entity to have a DID, as for the client/installer, trust only needs to exist in the package, with all other nodes in the chain being somewhat transparent.

On the other hand, the moderation spec requires the ability to assign trust labels not only to packages, but to Aggregators, Repositories, and potentially to other types of network nodes or entities. From the moderation spec:

Our moderation tools and systems are intended to provide federation participants with the ability to:

• Flag known malicious or harmful content.
• Label Repositories, packages or other content, and aggregators with meaningful trust signals (e.g., “verified,” “deprecated,” “security-risk”).
• Enable Aggregators to apply transparent and consistent filtering based on community-defined criteria.
• Offer users control over the moderation standards they subscribe to and follow.

Per @Ipstenu, the moderation spec does conceptually anticipate that a package may derive some types of trust signal from the repository. Although this could be extended to apply to the Author or Publisher as well, the FAIR Protocol does not address any of these entities in this context, as it does not conceive of as many types of specific entity as the moderation spec attempts to addresses. An unspoken assumption (more explicit in item 3 below) is likely that each entity has a DID to which labels may be applied, but the FAIR Protocol neither requires or uses DIDs for these.

Protocol: https://github.com/fairpm/fair-protocol
Mod Spec: https://github.com/fairpm/fair-protocol/tree/main/docs/moderation

2. Security: Supply Chain Threat/Risk Mitigation (Business Rules)

This relates to issues #4 which indicates a potential supply chain attack which could be mitigated by signing metadata. Also related are issues #43 & #45 both of which discuss tracing provenance to the Author rather than to the Package. The Protocol is designed to track provenance to the Package; Author is not an entity in the protocol, just a potential attribute (meta) for the Package. Issue #42 is also related, though somewhat indirectly.

In identifying supply chain risks and threats and how these are mitigated, it becomes apparent that some potential stakeholders (primarily hosts) may be looking for trust or accountability to be established for each node in the supply chain, from author to end user.

For example, the risk exists that a package could be published by someone who holds neither the copyright nor a license permitting its distribution. The moderation spec states that Repositories are responsible for the content they host and for verifying it, but the protocol does not assist in the process. At the same time, the Repository and other nodes must be able to have labels assigned to them under the moderation spec, but the protocol does not necessarily treat these as distinct entities which can be labelled or which need specific trust signals, at least on a technical level.

While the protocol is fully able to securely deliver and confirm the requested package, some of the types of non-technical (read: human) trust signals needed for stakeholder assurance will need to go beyond what is strictly required at the technical level.

Fundamentally, the protocol and the moderation spec are each written with a different concept of the business rules or needs they serve. Neither document fully specifies these business rules or “user stories” as applications of different use cases that they address.

3. Ozone Labeling Platform

Relates to issues #11 #35 & #44 regarding the architecture design for Labelling services. (Note the proposal outlined in #35 had general agreement, but the issue remains open since the architecture itself is only shown as a conceptual diagram so far. The technical implementation of the moderation spec plans are to use Bluesky’s Ozone labeller, which assigns labels to “Subjects”. As described there,

Subjects can be either entire accounts (referenced by a DID), or individual pieces of content (referenced by an AT-URI, and possibly a CID to specify which version). Note that an account profile record (including description, avatar, etc) is a distinct subject from the overall account. Subjects have state, are impacted by events, and can be reported.

By default, the Ozone labeller would presumably treat a package as “content”, which doesn’t need a DID, but may have a version. It's likely that anything with a DID could be treated as an “account” for the purpose of labelling, including packages, which would seem to be a different approach than Ozone's default design. Even if Ozone will work for us out of the box, we'll need a description of how we plan to use it, given the fundamentally different treatment of "content".

For an introduction to Labelling in Bluesky, see https://github.com/bluesky-social/proposals/tree/main/0002-labeling-and-moderation-controls

Next Steps

Resolving the issues referred to above, some of which may be considered duplicates, will all be blocked by this overarching issue.

Further analysis is needed to create a better assessment of the specific business rules surrounding risk mitigation and establishment of trust signals. It’s imperative we identify points at which the moderation spec and the technical aspects of the protocol may need adjustments to fully align with each other around addressing the necessary business rules, which will need further description in order to effectively implement them in a manner that addresses all stakeholder and user requirements.

With requirements defined based on (1) the necessary business rules and (2) any necessary changes identified for the FAIR protocol and moderation spec, the technical requirements for applying trust labels can be determined. Testing and analysis of the Ozone platform will be needed to determine whether it can be used as-is for a FAIR labelling service or to determine what changes it would require in order to meet FAIR’s needs for labeling, and whether the scope of any necessary changes would outweigh the utility of building with Ozone at all.

[Ipstenu]

As I understand it, @rmccue , the current Protocol spec is that ONLY a package has trust signal attached.

But we do want and need to be able to apply trust to Aggregators and Repositories. If it helps, think of the scale and scope. If a single Repository is a Bad Actor, we either flag the Repo as a bad one and defederate, or we end up playing whack a mole with all the packages, they add more, and so on and so on.

I wrote out the labeling protocol with that in mind, which is why I specifically asked you to look at that and tell me what was out of scope for the protocol so we could talk about it.

[rmccue]

When I was talking about making changes, I meant specifically to the install flow and the way the data flow works there; I agree that we want to be able to attach labels/trust to repos as entities.

We should also clarify the difference here between a repository and a vendor - a repository could be uniquely identified right now (by URL), whereas a vendor is not yet a concept that formally exists. Just like dotorg, packages can specify their authorship via (effectively) free text fields, with a name and a URL. If we want to identify vendors uniquely, that's a separate thing we should consider.

imo, it complicates things quite a bit to have moderation of packages, repositories, and vendors - I think just the first two are sufficient from what I've seen.

Adding vendors as a first-class object would increase the barrier to publishing, so it needs to be balanced against the benefits. I'm not seeing that we necessarily need this, but we can be somewhat flexible on it - but we should think through the implications there.

---

In re changing the protocol:

The installation pathway right now is:

flowchart LR
  classDef verif fill:#eee
  Client --> lookup["Lookup DID (and signing keys)"]
  lookup --> fetch_metadata["Fetch package metadata"]
  lookup --> verify_dns("Verify DNS TXT record"):::verif
  fetch_metadata --> fetch_release["Fetch release zip"]
  fetch_release --> verify_sig("Verify signature")
  verify_sig --> Install

Loading

With repository verification and labeling checks:

flowchart LR
  classDef verif fill:#eee
  Client --> lookup["Lookup DID (and signing keys)"]
  lookup --> fetch_metadata["Fetch package metadata"]
  lookup --> verify_dns("Verify DNS TXT record"):::verif
  lookup --> check_repo_labels("Check repo labels"):::verif
  lookup --> check_package_labels("Check package labels"):::verif
  fetch_metadata --> fetch_release["Fetch release zip"]
  fetch_metadata --> check_release_labels("Check release labels"):::verif
  fetch_release --> verify_sig["Verify signature"]
  verify_sig --> Install

Loading

What I meant was avoiding having any vendor/repository data "in line" with this primary data flow, and ensuring it can happen in parallel. This ensures we can keep things performant, and that we can layer the different aspects of the protocol on top of each other.

---

For labeling things, the main thing we need is a way to uniquely identify them. Packages have DIDs, and we can derive IDs for things "belonging to" the package - eg releases could be fair://{did}/releases/{release_version}.

We don't have IDs for repositories defined yet. Unlike with packages, this doesn't need to be decentralised or have data portability, so we can use the URL itself as the ID. Packages are tied to a single URL though (/packages/did:plc:...), so we need some way to get from that to a repo ID.

So long as we're OK with only one-repo-per-domain, I think we should treat the Origin as the repo ID - i.e. a package hosted at https://packages.example.com/foo/bar/quux/packages/did:plc:abcdef is therefore at a repo with ID https://packages.example.com. This simplifies identifying repos, at the slight cost that you can't run multiple repositories from the same subdomain (you can serve multiple packages just fine though).

The alternative would be that package metadata includes a (HAL) link to the repository it's hosted on, but that means potentially extra HTTP requests and also some weird questions around how it works. (What if it links to a different domain eg?) imo, not worth going into, I think we should just roll with the Origin.

---

In re Ozone:

We should probably avoid talking about Ozone generally, which is a specific labelling system for the AT Protocol. We might choose to fork it, or build something from scratch, but either way it's not an off-the-shelf solution and it's tied specifically to atproto.

In particular:

Subjects can be either entire accounts (referenced by a DID), or individual pieces of content (referenced by an AT-URI, and possibly a CID to specify which version).

Our system setup is different to atproto. A "subject" here is a package, "individual pieces of content" would be releases for that package. Ozone does not support labelling a PDS, which is the equivalent of our Repository - eg an Ozone labeler can't block https://porcini.us-east.host.bsky.network/ which is the PDS my account is hosted on. (There is, to my knowledge, no functionality in Bluesky implementing PDS-to-PDS blocking.)

We've identified that we do want to be able to moderate repositories. We need to decide if we want to be able to label repositories, or whether we just want to have a yes/no on federation with them.

[Ipstenu]

imo, it complicates things quite a bit to have moderation of packages, repositories, and vendors - I think just the first two are sufficient from what I've seen.

[...]

Adding vendors as a first-class object would increase the barrier to publishing, so it needs to be balanced against the benefits. I'm not seeing that we necessarily need this, but we can be somewhat flexible on it - but we should think through the implications there.

So by 'vendors' we're talking about aggregators here. Or at least I am.

The reason we moderate aggregators is to keep them honest.

If an aggregator isn't removing back repos or packages, or isn't properly updating security, then we need to yank it.

We should probably avoid talking about Ozone generally, which is a specific labelling system for the AT Protocol. We might choose to fork it, or build something from scratch, but either way it's not an off-the-shelf solution and it's tied specifically to atproto.

Valid. I'll go back over it :)

[rmccue]

So by 'vendors' we're talking about aggregators here. Or at least I am.

When I'm saying "vendor" here I mean what we call "authors" usually, but avoiding that term since it also encompasses contributors, etc - everyone who's listed as creating a package.

A Vendor is one who writes the code for a Package, and who hosts that Package on a Repository. They could operate their own Repository (ie self host with mini-fair-repo), or they could host it on a third-party repository (eg a dotorg, envato, etc etc).

VS Code's marketplace eg verifies vendors but not packages (note where the checkmark is):

Right now, neither dotorg nor FAIR have concepts of Vendors being a "real" object/entity, so we can't verify them - instead, we're verifying packages. This is generally safer: it's more granular, and it doesn't give extra trust to a new package by an existing vendor - eg RyanCo couldn't come along and use their existing verification to have a new trusted "Even More Secure Custom Fields" package automatically.

Hence the question here: do we need that in addition to the package verification? 🤔

[toderash]

I prefer not to use "vendor" because it implies a financial transaction, and does not necessarily imply as direct a relationship to the package: i.e., is a payment processor a vendor? (no).

What I'm talking about is publishes, which is similar to authors, but not necessarily identical. A publisher may be a "vendor" selling packages, but may also be a foundation, organization, or any other structure that publishes a package. An Author may also be the publisher, or a publisher may publish a package by many authors. The publisher is the licensor, and is described in https://github.com/fairpm/trust/blob/main/supply-chain/overview.md under "Author & Publisher".

wrt Ozone, I did specifically note above how it treats the material / data differently than we need it to, quoting its documentation, yes, that's the mismatch for it in the title. It's the obvious first thing to look at, but not a foregone conclusion. The 5th deliverable listed for the Trust WG is to evaluate "Ozone or alternatives, if available" (should be and rather than or) in order to determine how closely it would fit the business rules or what changes would be needed. (It'd be a tech implementation decision at that point to determine whether we fork or write from scratch.) It's likely we'll keep talking about it as an option in that context, but I agree nobody should assume it's an out-of-the-box thing, because we already know it won't be.

To @rmccue's diagrams, I'm not seeing this in quite the same way. I agree we don't want too much in line here for package installation, and it may be worth a future discussion about whether a client should have the option of getting cached labels from the aggregator along with the package meta, or performing its own checks directly... but that's a separate and later thing. For now, the client should be subscribed to the FAIR labeller for whatever labels it serves, so it's not querying repo labels separately from package (or any other) labels UNLESS the client is ALSO subscribed to an optional labeller. (Back to that in a minute.)

wrt Authors & Publishers as entities, I'm not certain if they need to be identified in the technical aspects of the chain per se, as they don't necessarily add anything to the technical implementation of delivering the package securely. They do exist conceptually, and need to be linked to the package in some fashion, and this is how they are very relevant to trust signals since you don't want to just secure the package download, you want to trust that it came from the proper publisher. Determining this is why the Trust WG exists: we need to work out what trust signals we need and only then, how they might reasonably be established.

For labeling things, the main thing we need is a way to uniquely identify them. Packages have DIDs, and we can derive IDs for things "belonging to" the package

Identifying packages is fundamental, but the reason to do so in this context is for applying trust labels, not just ID labels. These are very different, as you don't want to trust everything you can identify. The DID ensures we're talking about the same specific package, but the trust label is necessarily independent and supplied from outside of the package. In that sense, the package doesn't "own" the trust label and has no control over it. This means we have to have +1 external check added to the current diagram, being the FAIR Trust Labeller. I think we can work this into a single query by package DID. For example, the client could send a trust-check for package aggregated by from repo . The labeller can then return labels for everything in the chain. But that's getting ahead of ourselves.

The big thing here is that the discussion quickly starts to define how we will deliver the thing before we've defined what the thing is that we need. Again, that's why the Trust WG was formed, so we can define the set of trust signals we need: i.e., the business rules. Once we know what those are, we can define how to deliver them technically, and whatever can't be delivered technically must be done manually.

My takeaway so far here is (1) we're closer than it sounded and need to update some docs and terminology, but (2) before going too far in designing its architecture, we need to understand the requirements. This is kind of the issue: the protocol architecture describes the solution to a problem, but different sections of the protocol solve different problems which overlap but are not identical. Naturally, we need each section of the protocol to support the others, but none of them have a thorough description of the problem they are trying to solve.

[Ipstenu]

I prefer not to use "vendor" because it implies a financial transaction, and does not necessarily imply as direct a relationship to the package: i.e., is a payment processor a vendor? (no).

I have to agree here, "Vendor" is not the right term either and is confusing here (as evidenced by our confusion about what Ryan meant!)

• "Package Owner" - Entity who takes responsibility for the code (includes code author, owning company, etc)
• "Repository Maintainer" - Entity who manages the Repository and decides who gets hosted here (this would be the publishing entity)

wrt Authors & Publishers as entities, I'm not certain if they need to be identified in the technical aspects of the chain per se, as they don't necessarily add anything to the technical implementation of delivering the package securely. They do exist conceptually, and need to be linked to the package in some fashion, and this is how they are very relevant to trust signals since you don't want to just secure the package download, you want to trust that it came from the proper publisher. Determining this is why the Trust WG exists: we need to work out what trust signals we need and only then, how they might reasonably be established.

Now do we need the Package Owners as a DID entity?

That's a very interesting question. It could alleviate some of the drama when it comes to people selling a plugin to someone else. But more it could ping people that Company A changed their name. Then again ... it's hard enough to get people to remember that they should say "Company A is owned by Bigger Company Zed" so we would end up with a different DID for Woo, Jetpack, and so on, and that would be nuts. It wouldn't really help anyone :/

[toderash]

• "Package Owner" - Entity who takes responsibility for the code (includes code author, owning company, etc)
• "Repository Maintainer" - Entity who manages the Repository and decides who gets hosted here (this would be the publishing entity)

I think your "Package Owner" might be my "Author" or "Publisher", who may or may not be the same. I split them because they describe 2 overlapping roles. Calling them the "Owner" makes me think this is closer to "Publisher" as they would hold the copyright, but in a multi-author GPL project, the copyright could be held by 1,000+ different people, in which case none of them is the single "owner", but the "Publisher" issues the Packages under a valid license from all Authors.

"Repository Maintainer" might be oddly & unexpectedly ambiguous here. In the case of the non-Mini ("Mega"?) Repo, the person who maintains the repo is not the same as the Package Maintainer. In the case of Mini-FAIR, they're likely the same. That's okay though, just recognizing that this entity is a person or group filling a role that is relevant to the Trust Signals. "Aggregator Maintainer" would be relevant in the same way.

Still not determined if the individuals need a DID (we'll work that out in the coming weeks), but it's a bonus for trust if they have a verifiable one... which could technically just be a Bluesky account.