-
Notifications
You must be signed in to change notification settings - Fork 99
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
KBS-Protocol | Add AAEvidenceProvider
implementation
#868
KBS-Protocol | Add AAEvidenceProvider
implementation
#868
Conversation
Signed-off-by: Xynnn007 <[email protected]>
This feature enables dependencies to leverage ttrpc capabilities to connect to AA via ttrpc, thus `aa_ttrpc` is a better name for future extension. Signed-off-by: Xynnn007 <[email protected]>
b0ee403
to
77fe5f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After this commit, only CDH will access the KBS.
This change will require the KBS that does RCAR and stores resource be
the same in CoCo, s.t. background check model. which is up to now
nearly all the deployments we have met.This will not break the passport model because kbs_protocol crate still
provides a way for developers to integrate either passport model or
background check model in their own code.
Will coco deployments that provide individual resource-kbs and token-kbs's still work after this change?
If not, what would a user have to do to enable such a deployment?
So the key use case here is running multiple CDHs? Maybe we should have a discussion about supporting multi-KBS deployments more generally. I think we should try to have a standard way to enable multi-kbs workloads once init-data is supported. |
Ok. Currently CoCo deployments does not support the scenario where token-KBS and resource-KBS are different as they both are specified with The concrete case is for scenarios beyond CoCo:
Let me only leave the commits that add |
77fe5f1
to
198e196
Compare
AAEvidenceProvider
implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple nits but generally this seems ok.
I think we should discuss multi-kbs more generally. I don't really think we should use multiple CDHs. instead we can just add support for connecting to multiple KBSes in the CDH, but that's a topic for another time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this file should be called ttrpc.rs
to contrast with native.rs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the "provider" is AA, so maybe aa_ttrpc
is clearer?
AAEvidenceProvider gets evidence via ttrpc from AA. This patch also does some refactoring upon the code structure of ttrpc to avoid duplication of ttrpc files. Signed-off-by: Xynnn007 <[email protected]>
198e196
to
b255ba6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Let CDH get evidence rather than token from AA when doing get_resource based on RCAR.Add
AAEvidenceProvider
implementation to kbs-protocol crate