You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the key-broker always uses a Veraison service endpoint for verifications.
The rust-ccatoken repo offers an alternative verification mechanism, which is linked as a library rather than provided as a web service.
Integrating rust-ccatoken would allow the key-broker to demonstrate both service-style ("remote") and library-style ("local") verification of evidence. This would be of educational value because it broadens the set of possible RATS deployment patterns.
This would probably be implemented as a command-line switch to the server, which would start it up in a different mode where the Veraison challenge-response endpoint is not needed or used. Instead, it would use the verification function from rust-ccatoken and would only support the CCA evidence type.
This would not require any change (breaking or otherwise) to the API with the client. The interaction pattern there remains the same. The change in behaviour would be isolated entirely within the server.
When running in this mode, the server would probably need additional command-line config so that the verifier library knows where to get the endorsements and trust anchors from. In the future, this could also evolve to demonstrate the use of Veraison as an endorsement service, but that is not part of this feature request.
The text was updated successfully, but these errors were encountered:
Currently, the key-broker always uses a Veraison service endpoint for verifications.
The rust-ccatoken repo offers an alternative verification mechanism, which is linked as a library rather than provided as a web service.
Integrating
rust-ccatoken
would allow the key-broker to demonstrate both service-style ("remote") and library-style ("local") verification of evidence. This would be of educational value because it broadens the set of possible RATS deployment patterns.This would probably be implemented as a command-line switch to the server, which would start it up in a different mode where the Veraison challenge-response endpoint is not needed or used. Instead, it would use the verification function from
rust-ccatoken
and would only support the CCA evidence type.This would not require any change (breaking or otherwise) to the API with the client. The interaction pattern there remains the same. The change in behaviour would be isolated entirely within the server.
When running in this mode, the server would probably need additional command-line config so that the verifier library knows where to get the endorsements and trust anchors from. In the future, this could also evolve to demonstrate the use of Veraison as an endorsement service, but that is not part of this feature request.
The text was updated successfully, but these errors were encountered: