I was hoping to discuss https://github.com/tock/tock/pull/4028. That PR enables two features for AppID:

Allows an AppID assignment policy to use the accepted credential when assigning IDs. This is important if the AppId is the public key used to verify a signature, for example. (This functionality used to exist and I removed it previously because of how process loading changed. Turns out we still need it.)
Helps developers use the accepted credential correctly when assigning an AppID. There are two issues/pitfalls that can arise when trying to use an accepted credential to assign an AppID.

The checker, while verifying the credential, has some state about the verification process that is necessary for assigning the AppID. Some examples:

The checker maintains a list of valid public keys that can verify signatures. The checker knows which public key was used to verify the signature.
The checker knows if the app was signed by the kernel developer or a third party (or both).
The checker has multiple public keys per organization, and knows which one signed the app.

TBF footers are not checked for integrity, and developers must not store any values in the footer that cannot be verified by the checker. Very little can be verified by the checker. If a public key is in the credential, the checker can validate that that public key matches the signature. But any other data cannot be verified and could be modified before the app is loaded on a board.

To help with these issues, this PR also includes a `usize` that the checker can store with the accepted credential to provide information about the accepted credential that the AppID assignment policy can use.

For issue #1: this would allow the process checker to keep track of some metadata about why it accepted the credential. For example it might store the index of the public key that verified the signature. Or it might store the upper 16 bits of the ShortId for the organization that signed the app. The value is opaque, and different policies/implementations can use it differently. The `Compress` trait (ie assigning ShortId) is not asynchronous. So from a software engineering viewpoint, whatever state the AppId assignment policy needs must be fetched in advance, and the policy can not re-run any verification steps. Therefore, the checker needs some way to communicate with the AppId assigner if the assigner is going to use any outcome of the verification process in its AppId assignment.

For issue #2: this gives developers some way to attach state to an accepted credential without including that state in the credential itself. This isn't providing a correctness guarantee, but it is providing an alternative to what seems intuitively valid: just include it in the credential. Otherwise, developers that want to use different credentials to assign different AppIds can't (or have to build some sort of workaround).

- Brad