Greg:
I slipped up in here and used the term 'key' interchangably with
'capability.' In the EROS system, for historical reasons, we call
them keys.
Your description of the counter-based entry technique is plausible.
One minor detail that doesn't materially impact your proposed design: the question of how a key ID should be designed.
First, the ID should in most cases be opaque to the key holder. It is none of the key holder's business if two keys point to the same object with distinct key ID values or if they point to different objects -- this is an encapsulation argument, but there are some pragmatic reasons to want to adopt this having to do with what happens when you upgrade object(s). This might not be an issue for the counter system, but for other systems it's worth thinking out in advance.
For a variety of reasons, it is desirable for a capability to occupy a fixed amount of storage, and for all capabilities to be the same size. Imagine, by way of analogy, a system in which pointers of different types are different sizes or have differing interpretations. One of the early Crays actually did the latter, and it was a bloody nuisance.
As a result, there are practical limits on the size of the key ID that can be embedded within the capability. In EROS, the ID field is 16 bits. That much was easy to get without growing the capability, and in our experience it serves the needs of most applications. It is clearly inadequate for a card key system.
One EROS application that requires a larger ID space is the space bank, which is a sytem utility that buys and sells storage. Nominally there are many space banks, but in fact all space bank capabilities name the same object with distinct key IDs. Since space banks are fairly common, a large key ID space is required.
This is handled by using an indirection object. A key alleging to be an EROS space bank key is in fact a key to an indirection object (as it happens, we perverted a red segment for this purpose). The indirection object, among other options, has a mechanism for replacing one of the passed argument registers with a value taken from within the indirection object itself. By creating indirection objects with suitable ranges of values, a large key ID space (32 bits, though it could be made larger easily) is obtained.
The indirection involved is transparent to the caller, subject to the caveat that one of the passed argument registers has effectively been taken over by the indirection mechanism. In practice the caveat does not appear to be a problem.
shap