From c184d020de3492540a26618b4c6a561aa001f5bd Mon Sep 17 00:00:00 2001
From: Nick Santana <nick@mobilecoin.com>
Date: Fri, 1 Dec 2023 09:18:39 -0800
Subject: [PATCH 1/2] Add DCAP evidence to BlockMetadataContents

---
 text/0068-dcap-evidence-in-block-metadata.md | 92 ++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 text/0068-dcap-evidence-in-block-metadata.md

diff --git a/text/0068-dcap-evidence-in-block-metadata.md b/text/0068-dcap-evidence-in-block-metadata.md
new file mode 100644
index 00000000..4dbc1346
--- /dev/null
+++ b/text/0068-dcap-evidence-in-block-metadata.md
@@ -0,0 +1,92 @@
+- Feature Name: dcap-evidence-in-block-metadata
+- Start Date: 2023-12-01
+- MCIP PR: [mobilecoinfoundation/mcips#68](https://github.com/mobilecoinfoundation/mcips/pull/68)
+- Tracking Issue: [mobilecoinfoundation/mobilecoin#2373](https://github.com/mobilecoinfoundation/mobilecoin/issues/2373)
+
+# Summary
+[summary]: #summary
+
+Provide DCAP attestation evidence in the block metadata. This is the compliment
+to the Attestation Verification Report (AVR) used in EPID.
+
+# Motivation
+[motivation]: #motivation
+
+EPID SGX hardware is being phased out. The newer SGX machines use DCAP as the
+attestation protocol. This MCIP is to provide the DCAP version of the evidence
+in the block metadata so that chain integrity can be verified for blocks created
+on the newer hardware.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+The `BlockMetatdataContents` in block versions 4 or greater contain either a
+`DcapEvidence` or a `VerificationReport`.
+(The `BlockMetatdataContents` was added in [MCIP-0043](0043-block-metadata.md)).
+The `DcapEvidence` contains attestation evidence returned by the DCAP
+attestation process. The `VerificationReport` contains the attestatoin evidence
+returned by the EPID attestation process.
+
+In general, block version 4 or greater is expected to only contain
+`DcapEvidence`, but the `VerificationReport` is included for backwards
+compatibility.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+The `BlockMetadataContents` uses a
+[`oneof`](https://protobuf.dev/programming-guides/proto3/#oneof) to contain
+either a `VerificationReport` or a `DcapEvidence`. This field is named
+`attestation_evendence` to be generic enough to contain either type of evidence.
+
+## Protobuf schema
+
+```protobuf
+message BlockMetadataContents {
+    /// The Block ID.
+    BlockID id = 1;
+
+    /// Quorum set configuration at the time of externalization.
+    QuorumSet quorum_set = 2;
+
+    // The attestation evidence for the enclave which generated the signature.
+    oneof attestation_evidence {
+        external.VerificationReport verification_report = 3;
+        external.DcapEvidence dcap_evidence = 5;
+    }
+
+    /// Responder ID of the consensus node.
+    ResponderId responder_id = 4;
+}
+```
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+This requires a block version bump since it changes the `BlockMetadataContents`.
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+The `VerificationReport` and `DcapEvidence` were disparate enough that it didn't
+seem feasible to try and convert a `DcapEvidence` into a `VerificationReport`.
+
+While requiring a version bump, this change is able to be backwards compatible
+such that clients only knowing about version 3 can still consume the blocks.
+They will **not** be able to perform verification due to lacking the necessary
+evidence.
+
+# Prior art
+[prior-art]: #prior-art
+
+None at this time.
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+None at this time.
+
+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+None at this time.

From 3f41d0b2587cf26c663afdd14b311d08aaa3c93f Mon Sep 17 00:00:00 2001
From: Nick Santana <nick@mobilecoin.com>
Date: Mon, 4 Dec 2023 07:40:30 -0800
Subject: [PATCH 2/2] Remove wording of non breaking change

Moved mention of older clients being unable to verify the newer version
into the drawbacks section.
---
 text/0068-dcap-evidence-in-block-metadata.md | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/text/0068-dcap-evidence-in-block-metadata.md b/text/0068-dcap-evidence-in-block-metadata.md
index 4dbc1346..4975b6b6 100644
--- a/text/0068-dcap-evidence-in-block-metadata.md
+++ b/text/0068-dcap-evidence-in-block-metadata.md
@@ -64,6 +64,8 @@ message BlockMetadataContents {
 [drawbacks]: #drawbacks
 
 This requires a block version bump since it changes the `BlockMetadataContents`.
+Consumers that only know about block version 3 will be unable to verify
+`BlockMetadataContents` or the attestation evidence it contains.
 
 # Rationale and alternatives
 [rationale-and-alternatives]: #rationale-and-alternatives
@@ -71,11 +73,6 @@ This requires a block version bump since it changes the `BlockMetadataContents`.
 The `VerificationReport` and `DcapEvidence` were disparate enough that it didn't
 seem feasible to try and convert a `DcapEvidence` into a `VerificationReport`.
 
-While requiring a version bump, this change is able to be backwards compatible
-such that clients only knowing about version 3 can still consume the blocks.
-They will **not** be able to perform verification due to lacking the necessary
-evidence.
-
 # Prior art
 [prior-art]: #prior-art