[Someone please supply a link/text describing the exact form[s] of this conundrum, which I will happily replace this text with.]
Hoo-boy! There is a lot to unpack here. Any thoughts about where to start?
There’s exposing interfaces [bridges] such as HTTP on port 80…
There’s presenting credentials for possible Web SSO…
So many things…
Correct me if I’m wrong (I’m still fairly inexperienced with capabilities) but is the issue you’re referring to “wrapping” credentials that might be passed through a membrane when bridging to a non-ocap system?
For example, you’re communicating with an HTTP API through a revocable membrane, and the API hands you a token to use for future requests. If the membrane isn’t aware that this is a credential, it’ll just be handed back to you unchanged in the response data - and can be used even after your access through the membrane is revoked.
@jfred I think what @frandallfarmer means here is that CapTP is a membrane… and obviously our preferred distributed systems path. But compatibility layers to eg ActivityPub, but really every other interop layer we’re doing, will also be done as membranes.
More to expand on here, it’s late and I’m sleepy! 
We designed a system for HP Enterprise Services that had a membrane-like problem. Unfortunately, the team got laid off before the design was implemented, so there are certainly problems I’m not aware of.
Large companies use hundreds of cloud services, which makes it hard to manage their interactions with them. The product we designed mediated all interactions between a company’s employees and the cloud services they used, allowing HP to manage those services on behalf of HP’s client companies. It was important that employees not be able to go directly to the cloud services. In effect, we had to implement the behavior of a membrane even when we couldn’t confine user communications.
The basic design was capability based, with the service capabilities (OAuth tokens) in sealed boxes (encrypted blobs). Each user had a capability to a proxy that could unseal the box holding the capabilities to the service. There was also a per-service proxy for each user that encrypted capabilities being sent to the user.
This design gave us a place to stand for non-OAuth services. The proxy created the account on behalf of the user and gave them to the user in the form of an encrypted blob. A user would invoke a capability to their proxy along with the encrypted credentials. The proxy would then login to the service and forward requests compatible with the capability used to invoke it.