-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose init_data to policy #370
Comments
That's good points and I agree to provide them into OPA. Overall I think KBS is the right place to check plaintext of initdata and potential runtime data rather than AS. Let's see the whole lifetime of initdata and see what we should do
|
Yeah, I think we'll need to extend CheckInitData in the AA to get the plaintext in the first place. The AA should probably store the plaintext somewhere until it is time for attestation. We could potentially use one of the extra-params fields in the KBS protocol for the initdata, but unfortunately the attestation message doesn't have that field. I guess we could pass it as part of the request but that seems kind of weird. Once we're into the KBS, we should double check that all the verifiers are actually validating the initdata and then just pass it into the Regorus engine. |
Now that the init_data spec is merged, we should think about how we will evaluate the init data with Trustee.
Currently we don't really expose the init_data to either the attestation policy or the resource policy in the KBS. We had talked about extending the claims map of each verifier to include init_data, but that hasn't really happened. Maybe we should instead directly provide the init_data to opa engine in addition to the claims map? Should we do this for both the AA and KBS?
The text was updated successfully, but these errors were encountered: