There are two levels of protection in the Trove design. Which will operate depends on whether a contributor is authenticated or not.
The contributor who creates a package entry, and anyone who changes the package metadata or resources after the fact, will be put on the package's heads-up list. Every time the package metadata is modified after that, the updating contributor will be added to the heads-up list, and everybody on the heads-up list will be notified.
The intent of this feature (and the requirement that unsubscription requests be validated) is to make sure that all metadata & resource changes are visible to everybody with a stake in the package. In particular, any modifications an unauthorized person succeeds in doing will be visible to the real package owners.
Either a resource or a package may be locked. When an item (resource or package) is locked, any request to modify it must be authenticated as coming from a maintainer of the package.
Here are the rules of maintainership:
1. The owner of an item is the person who can add and delete maintainers.
2. Any maintainer of an item (package or resource) can modify or delete the item.
3. The maintainers of a package may delete associated resources.
The Trove authentication system leverages the PGP-key infrastructure. To authenticate a TRL request, you must sign it with PGP. The shovel program will check the signature. If the key ID matches the TRL Contributor line, the request is considered authenticated.
The big advantage of this system is that it leverages the public-key infrastructure. This means that Trove won't need to keep any secrets of its own, and contributors don't need any secrets other than their existing PGP passphrases.
To be specified. Base on the JAR approach suggested by Jeremy Hylton?