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
Today we have to select which token verifier we want to use at configuration time. The KBS can't handle connections from multiple guests that got their tokens from different types of verifiers.
This probably isn't too big of a deal, but worth noting.
The text was updated successfully, but these errors were encountered:
Also note that different tokens store the tee pubkey in different places. We have the logic to extract this in the attestation code, which is not very generic. We might want to move this logic into the token verifier code.
Nice idea. Luckily current ASes generate tokens all in JWT format, e.g. CoCo-AS Simple token, ITA Token, and potential EAR. So the difference would be the path of the tee public key of the JWT claim body. Most codes are the same.
The question is how would KBS detect the concrete kind of the JWT token runtimely. Probably the iss field of the JWT? But CoCoAS could specify random issuer name when launching.
Today we have to select which token verifier we want to use at configuration time. The KBS can't handle connections from multiple guests that got their tokens from different types of verifiers.
This probably isn't too big of a deal, but worth noting.
The text was updated successfully, but these errors were encountered: