Background: An Enveloped Signature is a Digital Signature Document/Object that contains both the signature block and the content that is signed.  Enveloped signatures do not include their own value in the calculation of the Signature. Resolution: In addition to time and budgetary constraints, a single JSON based Enveloped Signature method vs allowing for multiple options is mandated to simplify implementation. Benefits: Single object: Bind both a document and the signature into one document no risk signature document and content documents will be made unavailable through revision or access control.  Granularity: The Enveloped Signature Option supports one document per signature document.  Can be used when there is no Document Sharing infrastructure (ask John what this means) Covers all transactions described in CDEX:    - Search Bundles which can be attested by systems    - FHIR Documents (for Task Based Queries and Attachments) - "an immutable set of resources with a fixed presentation that is authored and/or attested by humans".         -  Avoids many of the issues with "How to handle when References are included in the resource being signed?" The workflow may involve data being retransmitted and the delivery mechanisms doesn't allow transmitting multiple disjoint resources. Provenance signatures are about retaining signatures on a per version basis. In our use-case, there's no updating of the data, just a single exchange. There are many design decision when constructing a FHIR implementation guide - each with its own set of trade-offs. There is little value in documenting unused options which could expose future version of the guide to unnecessary rehashing of design decisions and throttle adoption due to concern about future breaking changes.