Summary

  • RFC 9670 standardizes Principals, ShareNotifications and a sharing framework, but each data type still defines what rights mean and what may be shared.
  • A successful shareWith update must be followed by Principal verification, recipient myRights readback, notification evidence, an exercised operation and a separately scoped revocation test.

The owner selected a colleague, granted read and update rights, and received a successful JMAP /set response. The object's state advanced. The new Principal ID appeared in shareWith. Yet the colleague's client showed no object, and a direct update returned a permission error.

Nothing in that sequence necessarily means the standard failed. It means the word “shared” was asked to carry several facts that RFC 9670 deliberately keeps apart.

The RFC defines a common model for collaborative systems. A Principal can be a person, group, room, projector or another entity. Accounts can be associated with Principals. Shareable data types add three properties: isSubscribed, the user's current domain-specific myRights, and shareWith, a map from Principal IDs to rights. ShareNotification records a permission change for a recipient.

That is valuable coordination. Mail, calendars, contacts and future JMAP data types can reuse one grammar instead of inventing unrelated identity and sharing shapes. But RFC 9670 does not define what may be shared or the granularity of permission. Those choices belong to each data type. It also leaves Principal management outside scope because directory and account systems differ.

A Principal ID is a routing key, not a human proof

The first boundary is identity. A shareWith key names a Principal object. The Principal can expose a name, email, type and associated Accounts, but those display properties do not prove which human controls it.

RFC 9670 makes the danger explicit. If users can edit Principal names, descriptions or similar fields, one user can resemble another. Rejecting exact duplicate names is insufficient because misspellings and visually similar Unicode characters can still mislead. The server may forbid edits and should retain an audit trail.

For an operator, the receipt therefore starts before shareWith. Record the immutable Principal ID, the directory generation or authoritative identity reference, the Account containing that Principal and the owning Principal of the object Account. A screenshot of “Joe Bloggs” is presentation evidence, not identity evidence.

The owner is also special. RFC 9670 says the Account owner's rights are implicit and the owner must not be placed in the shareWith map. Absence from the map does not mean absence of authority.

Requested rights and current rights are different surfaces

shareWith expresses rights assigned to named Principals. myRights expresses the current user's permissions on the object. Both use a string-to-Boolean shape, but the keys and semantics are defined by the specific data type.

A successful update proves the server accepted a mutation. It does not prove a downstream client interpreted the rights, that server policy did not reduce them, or that a read, update, destroy or admin operation will succeed. The operational test is a join: owner-side shareWith, recipient-side myRights, then one narrowly scoped operation performed as that recipient.

Concurrency matters because shareWith is a map. Two administrators can read the same version, make different edits and each send a replacement. RFC 8620 supplies ifInState: the /set aborts with stateMismatch if the data type has moved. The response also separates updated from notUpdated. The state token protects a synchronization decision; it is not a generic audit record and does not identify a human intention.

Store the prior state, exact map hash, precondition, per-object result and new state. Without them, “saved” may mean that one administrator silently removed another's grant.

Permission is not subscription, and notification is not attention

RFC 9670 explicitly separates permission from interest. A user may be allowed to access many resources but subscribe only to a few. isSubscribed=false can explain why a legitimate share is absent from the normal view. A server can even reject subscription to a resource despite permission to access it.

This distinction changes the evidence question. “The object is missing from the sidebar” is not the same as “access was denied.” Querying the Principal's Accounts and directly fetching the object tests permission; inspecting subscription and client presentation tests visibility.

ShareNotification is another separate surface. The server should create one when rights change, but it may omit group-derived changes when volume would be overwhelming. It may coalesce records, cap storage, expire old entries or delete the oldest when full. The RFC warns that eviction can hide a security-relevant change.

A notification ID therefore proves that the server created a record under its policy. It does not prove delivery to a client, display to a person, comprehension or successful use. Old and new myRights, the affected item and changedBy are useful, but changedBy.principalId may be null.

Revocation closes live authority, not every copy

The most dangerous compression happens at revocation. Removing a Principal from shareWith, reading back reduced myRights and proving that a new live operation is denied can establish that the service's current authorization changed.

It cannot retroactively erase data that was legitimately exported, copied or cached outside the service while access existed. RFC 9670 does not define offline-copy control. “Revoked” must therefore state its subject: new server operations denied at a particular generation and time. It must not imply that every byte previously obtained has disappeared.

The RFC's security analysis reinforces this layered view. Editable Principal data can support spoofing. Brief access to an unlocked client can become persistent compromise if an attacker adds sharing to a controlled Principal. Repeated share changes can exhaust notification resources. An uncontrolled Principal population increases accidental disclosure, abusive sharing and notification spam.

The common failure is not insufficient syntax. It is allowing a true statement at one layer to impersonate the next. The server accepted a map. The state advanced. A notification existed. The user saw a card. None of those facts alone proves the intended person performed the intended operation—or that revocation recovered every copy.

Sources