Update the interaction between AA and CDH #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]>
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]>
Xynnn007
force-pushed
the
aa-move-to-cdh
branch
from
b0ee403 to
77fe5f1
Compare
There was a problem hiding this comment.
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 |
Xynnn007
force-pushed
the
aa-move-to-cdh
branch
from
77fe5f1 to
198e196
Compare
Let CDH get evidence rather than token from AA when doing get_resource based on RCAR.