Token not specified in kbs_types

[tylerfanelli]

The token returned by the kbs/attest endpoint is not defined in kbs_types. It is defined in the guest_components repository, however.

For clients looking to avoid having to use that repository, a similar definition for Token (or some standardization of what a token actually contains, rather than just three separate base64-encoded strings that are comma separated) with serde::{Deserialize, Serialize} in kbs_types would be useful.

[mythi]

(or some standardization of what a token actually contains, rather than just three separate base64-encoded strings that are comma separated)

The token returned is a JSON Web Token.

[tylerfanelli]

(or some standardization of what a token actually contains, rather than just three separate base64-encoded strings that are comma separated)

The token returned is a JSON Web Token.

Thanks for clarifying.

Will a JWK be the only response every found in the /attest endpoint? If so, it may be able to return something that implements serde::{Deserialize, Serialize} like so:

AttestationResponse {
    token: Jwk,
}

You can then sync the response expected between client and server with a shared type. I'm trying to avoid the case where something changes on server side that isn't subsequently changed in client.

Just a suggestion. If the only response ever from the server is a JWK (and is expected to stay that way) then I guess this can be worked around.

[Xynnn007]

There are some things that are not explicitly mentioned in the protocol documentation, but are present in the code implementation.

The actual communication steps in code is

1. Client sends Request to KBS
2. KBS response Challenge to Client
3. Client sends Attestation to KBS based on Challenge
   4. KBS returns a thing to Client. This thing is not defined in the document and now a plaintext of JWT in implementation.
4. KBS replies to that request with an Attestation Results Token.
5. Client requests for a resource.
6. KBS returns the resource in Response shape (JWE).

I suppose that you are thinking of what step 4 returns.

The KBS protocol is designed for generic remote attestation requests, which means that the response it ultimately returns does not necessarily have to be an Attestation Token; it could be anything else. Therefore, I don't really recommend adding this specific implementation to the kbs-types library. It still can be anything. wdyt?

[mythi]

4. KBS returns a thing to Client. This thing is not defined in the document and now a plaintext of JWT in implementation.

It is: "If the attestation was successful, the KBS replies to that request with an Attestation Results Token."

[tylerfanelli]

So because it's defined, should it be included? Or do you still feel the same way, that it should be left up to user?

@Xynnn007

[Xynnn007]

I prefer to leave to user. Now the core logic of the protocol is

1. return an endorsed public share of a tee key. Now it is in an attestation token (JWT)'s claims
2. Use the endorsed tee key to encrypt the secret from KBS.

So it doesn't matter what form the public key is returned in. This means that users can define how to return the public key used to encrypt resources. They can return it directly, or they can embed the key in the Attestation Token like the current KBS, or any way else.

[tylerfanelli]

Sounds good, thanks. Closed.