Okay I think I have a better handle on the workflow now. There's 4 hierarchies of trust and you only care about the storage one for my purposes. You can deterministically derive a parent key that's unique to your application based on non confidential secrets. Then from there you can start adding child keys, which when loaded into the module under the parent context can be used to wrap-encrypt your actual key used for decrypting whatever from disk. I'm not quite sure if or why the additional child key is needed but it makes sense you would have some additional indirection beyond the deterministic root key.
There's places to put in particular stuff like a pin or password so you can tie in a user there or just hard code it (or omit, in some cases?).
Anyways, I suppose all this is to achieve that if someone tries to decrypt your stuff with a different TPM it won't work.
I do wonder if you could use the determined root key public certificate to enrol a device as trusted and so long as the server sent you whatever encrypted using the public key it knwlew you'd only get access to it without hardware changes. Though that gets tricky, probably where the attestation/vendor truest hierarchy comes in.
#TPM #TPM2