Ines Robles IOTDIR review about architecture HOT 5 CLOSED

Page 9: we consider it always unidirectional, and don't find a case where we need bidirectional support. A TEEP Agent inside TEE doesn't call back and out to TEEP Broker inside a REE.

On IoT, let me ask our peers for input. @hannestschofenig how do you think about IoT device type that can apply the TEEP?

Page 27: we think of a group public key in a verifier to confirm that a list of devices are recognized in an attestation flow. A class can be a general device group name that the Verifier understands. At times, this can be a group ID for a set of devices that associate with an EPID public key, say, "EPID Group ID 1".

from architecture.

Ming writes:

Page 27: we think of a group public key in a verifier to confirm that a list of devices are recognized in an attestation flow. A class can be a general device group name that the Verifier understands. At times, this can be a group ID for a set of devices that associate with an EPID public key, say, "EPID Group ID 1".

Perhaps add an informative reference to draft-ietf-rats-daa as an example?

from architecture.

On IoT device class that TEEP can fit, we authors discussed and consider the following:

There is no clear spec from RFC 7228 to say which classes of IoT devices may fit. We will not specify it and leave such recommendation to the adopters. And the TEEP allows any code as long as the capacity fits.

from architecture.

Added the following changes about comment 3 for page 27:

"In some use cases it may be sufficient to identify
only the class of the device, for example, a DAA Issuer's group public key ID when the attestation uses DAA,
see {{I-D.ietf-rats-daa}}."

from architecture.

Added Ines's confirmation on the fixes: https://mailarchive.ietf.org/arch/msg/teep/qxYx2E2_Z8oHEegnf7FFZ7BTAhA/

from architecture.